Use resource_bundles instead of resources in podspec
Closed this issue · 5 comments
What feature are you requesting?
Use resource_bundles
per CocoaPods' recommendation instead of resources
.
What would be the benefit of adding this feature?
Better compatibility. Name collisions can occur when using this library, requiring the dev to manually remove the Assets.car
file from the project's output paths.
What solution would be ideal for you?
A podspec of these libraries are published with resource_bundles
instead of `resources.
What alternatives have you considered?
Writing a script to fix build failures.
Hi Jason, would you be free to tell us more details about the issue so that we can investigate the issue further and reproduce locally?
- What conflicts are you experiencing?
- Can you include the script you used to fix build failures?
- How to reproduce on a clean project?
This will allow us to further understand the issue and work towards a resolution.
This GitHub issue for MessageKit has a detailed explanation of the general problem: MessageKit/MessageKit#1573
Right now, it's hard to reproduce this issue fully because it occurs when using pod static framework, and there's another bug with pod static framework in the headless SDK: Azure/azure-sdk-for-ios#1539
But once that issue is resolve and static framework is supported, then users of the UI library will begin to see problems described in that MessageKit issue.
Thanks for your response, we will investigate the information provided and discuss our options internally before our next response.
Could you please clarify if you are using the Calling UI SDK or Chat UI SDK? This will help us prioritize which SDK's to target first to resolve this issue.
Calling SDK
After a detailed discussion within our team, I regret to inform you that we do not have plans to support resource-bundles in our iOS library/framework at this time. This feature primarily impacts static frameworks, and as such, we currently have no plans to support static frameworks in the future. This decision is based on our long-term strategic direction and the need to prioritize resources to deliver the most value to our users.
As a result, we will be closing this issue. If you have any further questions or concerns, please do not hesitate to reach out to us.