Thank you for your response to my previous feedback , confirming that registering custom ContactProviderDomain identifiers is a known limitation and currently unsupported. I am submitting this follow-up to seek clarification on this limitation and request improvements to the documentation to prevent confusion for other developers.
Background:
The ContactProvider framework allows creating a ContactProviderDomain with a custom identifier, but initializing ContactProviderManager with any identifier other than "defaultDomain" results in a ContactProviderError.domainNotRegistered error. Your response clarified that custom domains are unsupported, but the documentation does not explicitly state this limitation, leading to confusion.
Questions for Clarification
Future Support:
Is there a plan to support registering custom ContactProviderDomain identifiers in future iOS versions (e.g., iOS 18.2, iOS 19.0)? If so, can you provide an estimated timeline?
If custom domains will remain unsupported, can this be confirmed as a permanent design decision?
Documentation Improvement:
Can the documentation for ContactProviderDomain and ContactProviderManager be updated to explicitly state that only the "defaultDomain" identifier is supported, to avoid misleading developers?
Can additional guidance be added to explain why custom domains are unsupported or suggest alternative approaches for managing multiple contact groups?
Alternative Approaches:
For apps needing to categorize contacts (e.g., personal vs. business), what is the recommended approach within the ContactProvider framework, given the lack of custom domain support? For example, should developers rely on ContactItem.Identifier prefixes?
Are there plans to introduce new APIs (e.g., register(domain:)) to support custom domains or other contact organization methods?
Error Clarity:
Can the documentation for ContactProviderError.domainNotRegistered clarify that this error occurs due to the lack of custom domain support, rather than a configuration issue?
Impact:
The lack of clear documentation and the unsupported custom domain feature cause confusion and wasted development time. Developers may assume custom identifiers are functional due to the ContactProviderDomain API, only to encounter errors. Clarifying this limitation and providing alternative solutions would greatly improve the developer experience.Suggested Actions: Update the documentation to explicitly state that only "defaultDomain" is supported for ContactProviderDomain.
Provide guidance on alternative methods for categorizing contacts.
If custom domains will be supported in the future, include a note about planned enhancements.
