WalletConnect
Make groupIdentifier optional
Is your feature request related to a problem? Please describe. We can't simply update the WalletConnect SDK, since now the groupIdentifier is required. I am required to create an App Group in the Apple Developer Portal. Context: Networking.configure(groupIdentifier: <String>, projectId: <String>, socketFactory: SocketFactory()) https://docs.walletconnect.com/api/core/relay#networking-client-configuration https://github.com/WalletConnect/WalletConnectSwiftV2/issues/1264#issuecomment-1880469667
Describe the solution you'd like Make groupIdentifier optional. Not all apps are interested in your Notify API.
Additional context I think it is too far reaching that you feel entitled to make app developers mandatory changes that even touch app provisioning and keychain levels, for questionable functionality that an app may not want. This kind of behavior and engineering choices not only create a lot of work for developers who are trying to stay updated, it also actively discourages people from following your releases, complying with new standards or supporting WalletConnect at all.
Exactly, I can't connect without an entitlement file, I don't need group feature.
Auth token creation error: OSStatus: -34018, message: A required entitlement isn't present.
For iOS new declaration API, I need to update the library but getting above mentioned error.
Auth token creation error: OSStatus: -34018, message: A required entitlement isn't present.
It's been 3 weeks since the issue has been opened. Please at least acknowledge and communicate how you will handle this problem.
Together with #1319 , this will make it impossible for apps to submit an update after May 1, if they refuse to add App Groups, or not allowed to do so. So in practice, you are pushing a requirement to wallets, that opens up another attack vector, for some functionality they may not need. Please make this function optional until May 1, so people can actually update your SDK.
From Apple documentation:
An App Group allows multiple apps developed by the same team to access one or more shared containers. It also enables additional inter-process communication between those apps using Mach IPC, POSIX semaphores and shared memory, and UNIX domain sockets, among other IPC mechanisms.