Is your feature request related to a problem? Please describe.
Yes. We are developing an enterprise iOS application distributed internally where dependency size and overall application footprint are important considerations.
The Azure Communication Calling iOS SDK framework package is currently approximately 54 MB when downloaded, which introduces a significant dependency size overhead during integration. Even when only a subset of calling functionality is required, the full SDK must be included.
This creates challenges related to:
• Overall application binary size management
• Dependency footprint within enterprise applications
• Build artifact size and repository management
• Internal distribution efficiency and download performance
Currently, there is limited flexibility to include only the required calling components.
Describe the solution you'd like
We would like to request SDK size optimization improvements such as:
• A lightweight or minimal SDK distribution
• Modular SDK packaging allowing inclusion of only required features
• Separation of optional components into independent modules
• A size-optimized build variant without unused resources or capabilities
• Official guidance or tooling to help reduce SDK integration footprint
These enhancements would help enterprise teams integrate Azure Communication Calling features while maintaining manageable dependency sizes.
Describe alternatives you've considered
We have evaluated several approaches on the application side, including:
• Standard release build optimizations
• Binary stripping and architecture analysis
• General IPA size reduction strategies
• Framework analysis for unused components
However, the majority of the dependency footprint originates from the SDK framework package itself, limiting further reduction from the application level.
Additional context
• Application type: Enterprise iOS application (internal distribution)
• SDK framework download size: ~54 MB
• Only calling functionality is currently required
• Size optimization would significantly help enterprise adoption where dependency footprint matters
Is your feature request related to a problem? Please describe.
Yes. We are developing an enterprise iOS application distributed internally where dependency size and overall application footprint are important considerations.
The Azure Communication Calling iOS SDK framework package is currently approximately 54 MB when downloaded, which introduces a significant dependency size overhead during integration. Even when only a subset of calling functionality is required, the full SDK must be included.
This creates challenges related to:
• Overall application binary size management
• Dependency footprint within enterprise applications
• Build artifact size and repository management
• Internal distribution efficiency and download performance
Currently, there is limited flexibility to include only the required calling components.
Describe the solution you'd like
We would like to request SDK size optimization improvements such as:
• A lightweight or minimal SDK distribution
• Modular SDK packaging allowing inclusion of only required features
• Separation of optional components into independent modules
• A size-optimized build variant without unused resources or capabilities
• Official guidance or tooling to help reduce SDK integration footprint
These enhancements would help enterprise teams integrate Azure Communication Calling features while maintaining manageable dependency sizes.
Describe alternatives you've considered
We have evaluated several approaches on the application side, including:
• Standard release build optimizations
• Binary stripping and architecture analysis
• General IPA size reduction strategies
• Framework analysis for unused components
However, the majority of the dependency footprint originates from the SDK framework package itself, limiting further reduction from the application level.
Additional context
• Application type: Enterprise iOS application (internal distribution)
• SDK framework download size: ~54 MB
• Only calling functionality is currently required
• Size optimization would significantly help enterprise adoption where dependency footprint matters