iOS SDK सेटअप में CocoaPods फ्रेमवर्क हस्ताक्षरों (Signatures) को कैसे हल करें

iOS SDK को एकीकृत करते समय आप CocoaPods फ्रेमवर्क हस्ताक्षर त्रुटियों को कैसे ठीक करते हैं? डेवलपमेंट टीम त्रुटि को ट्रिगर करने वाले प्रभावित गैर-निष्पादन योग्य संसाधन-बंडल (resource-bundle) लक्ष्य का निदान करें, और फिर हर बंडल में वैश्विक स्तर पर हस्ताक्षर अक्षम करने के बजाय टारगेट-स्कोप्ड CocoaPods post_install ओवरराइड लागू करें।

प्रभावित CocoaPods/Xcode कॉन्फ़िगरेशन में, जनरेट किए गए संसाधन-बंडल लक्ष्य ऐसे हस्ताक्षर सेटिंग इनहेरिट कर सकते हैं जिसके कारण Xcode एक डेवलपमेंट टीम का अनुरोध करता है। इन बिल्ड विफलता को हल करने के लिए गैर-निष्पादन योग्य संसाधन उप-लक्ष्यों के लिए हस्ताक्षर आवश्यकताओं को अक्षम करने हेतु कस्टम Podfile post_install बिल्ड हुक कॉन्फ़िगर करने या मैन्युअल XCFramework एम्बेडिंग प्रोटोकॉल निष्पादित करने की आवश्यकता होती है।

Xcode 15 और 16 कोड साइनिंग नियम iOS SDK CocoaPods बिल्ड को क्यों तोड़ते हैं

Xcode बिल्ड टूल्स और रिसोर्स बंडल साइनिंग

Xcode 15 से शुरू होकर और Xcode 16 तक जारी रखते हुए, Xcode की बिल्ड सिस्टम में संशोधनों ने यह बदल दिया है कि कोड साइनिंग सेटिंग्स जनरेट किए गए उप-लक्ष्यों (sub-targets) तक कैसे प्रसारित होती हैं। प्रभावित Xcode और CocoaPods कॉन्फ़िगरेशन में, गैर-निष्पादन योग्य संसाधन-बंडल लक्ष्य जो PrivacyInfo.xcprivacy, एसेट कैटलॉग, या स्थानीयकृत स्ट्रिंग्स जैसे संसाधनों को पैकेज करते हैं, वे ऐसे कोड साइनिंग सेटिंग्स इनहेरिट कर सकते हैं जो Xcode को डेवलपमेंट टीम का अनुरोध करने के लिए प्रेरित करते हैं।

यह समस्या CocoaPods टारगेट जनरेशन के भीतर एक बिल्ड-सिस्टम इंटीग्रेशन बेमेल का प्रतिनिधित्व करती है, न कि एक सख्तApple नीति का जिसके लिए प्रत्येक स्वतंत्र, गैर-निष्पादन योग्य संसाधन बंडल को एक स्वतंत्र कोड हस्ताक्षर की आवश्यकता होती है।

संकलन त्रुटि की शारीरिक रचना (Anatomy): Signing for Target Requires a Development Team

CocoaPods का उपयोग करके निर्भरता को एकीकृत करते समय, निर्भरता प्रबंधक एक अलग Pods.xcodeproj प्रोजेक्ट जनरेट करता है जिसमें प्रत्येक पॉड और उसके संबद्ध संसाधन बंडलों के लिए अलग-थलग लक्ष्य होते हैं। आर्काइव निर्माण या सिम्युलेटर संकलन के दौरान, Xcode libOpoInstallSDK-OPPrivacy या Pods-YourApp-resource-bundle जैसे नामों वाले लक्ष्यों का मूल्यांकन करता है।

संकलन एक विशिष्ट बिल्ड त्रुटि के साथ विफल हो जाता है:

Signing for "libOpoInstallSDK-OPPrivacy" requires a development team.
Select a development team in the Signing & Capabilities editor.

चूँकि CocoaPods pod install चलाने पर इन उप-लक्ष्यों को गतिशील रूप से (dynamically) जनरेट करता है, इसलिए Xcode GUI के भीतर मैन्युअल रूप से डेवलपमेंट टीम सेट करना अल्पकालिक (ephemeral) होता है। pod install को फिर से चलाना या किसी स्वच्छ CI/CD वर्कर पर निर्माण करना प्रोजेक्ट फ़ाइल को ओवरराइट कर देता है, जिससे बिल्ड त्रुटि दोबारा होने लगती है।

CocoaPods उप-लक्ष्य गोपनीयता मेनिफेस्ट बंडलों के लिए बिना हस्ताक्षर वाली प्रॉपर्टीज़ को कैसे इनहेरिट करते हैं

कुछ CocoaPods पॉडस्पेक जनरेट किए गए संसाधन-बंडल उप-लक्ष्यों के माध्यम से गोपनीयता मेनिफेस्ट को पैकेज करते हैं (उदाहरण के लिए, resource_bundles घोषणाओं के माध्यम से), जबकि अन्य विक्रेता-प्रदानित (vendored) फ्रेमवर्क या सीधे संसाधन घोषणाओं के अंदर मेनिफेस्ट भेजते हैं।

प्रभावित CocoaPods कॉन्फ़िगरेशन में, एक जनरेट किया गया संसाधन-बंडल उप-लक्ष्य में उपयोग योग्य DEVELOPMENT_TEAM मान की कमी हो सकती है या हस्ताक्षर सेटिंग्स इनहेरिट हो सकती हैं जो Xcode को एक का अनुरोध करने का कारण बनती हैं। नतीजतन, जबकि मुख्य एप्लिकेशन टारगेट एक वैध प्रोविजनिंग प्रोफ़ाइल के साथ बनता है, नेस्टेड संसाधन-बंडल उप-लक्ष्य Xcode के कोड साइनिंग प्री-फ्लाईट चेक को ट्रिगर कर सकता है। इस समस्या को हल करने के लिए Podfile स्तर पर एक लक्षित वर्कअराउंड या मैन्युअल फ्रेमवर्क एम्बेडिंग में संक्रमण की आवश्यकता होती है।

फ्रेमवर्क बंडल साइनिंग त्रुटियों को ठीक करने के लिए Podfile बिल्ड हुक कैसे कॉन्फ़िगर करें

CocoaPods post_install निष्पादन हुक को समझना

CocoaPods Podfile के भीतर post_install नामक एक Ruby-आधारित लाइफसाइकिल हुक प्रदान करता है। यह हुक ठीक उस समय निष्पादित होता है जब CocoaPods Pods.xcodeproj प्रोजेक्ट फ़ाइल जनरेट करना समाप्त कर लेता है, लेकिन डिस्क पर लिखने से पहले। इस चरण में प्रोजेक्ट जनरेशन को इंटरसेप्ट करके, डेवलपर्स जनरेट किए गए लक्ष्यों के माध्यम से प्रोग्रामेटिक रूप से पुनरावृत्ति (iterate) कर सकते हैं, उनके उत्पाद प्रकारों का निरीक्षण कर सकते हैं, और Xcode द्वारा संकलन शुरू करने से पहले बिल्ड कॉन्फ़िगरेशन सेटिंग्स को संशोधित कर सकते हैं।

संसाधन बंडल उप-लक्ष्यों के लिए स्कोप्ड बिल्ड सेटिंग्स ओवरराइड का स्वचालन

स्थानीय विकास मशीनों और दूरस्थ CI/CD बिल्ड एजेंट दोनों पर बंडल साइनिंग त्रुटियों को हल करने के लिए, post_install हुक टारगेट नामों और उत्पाद प्रकारों का निरीक्षण कर सकता है। प्रत्येक CocoaPods संसाधन बंडल में वैश्विक स्तर पर कोड साइनिंग को अक्षम करने के बजाय—जो तृतीय-पक्ष निर्भरता में सुरक्षा जोखिम ला सकता है—डेवलपर्स को विशेष रूप से प्रभावित टारगेट बंडलों के लिए ओवरराइड को स्कोप करना चाहिए।

जब कोई टारगेट Apple के संसाधन बंडल उत्पाद प्रकार (com.apple.product-type.bundle) से मेल खाता है और नामित टारगेट नामों से मेल खाता है, तो स्क्रिप्ट CODE_SIGN_IDENTITY बिल्ड सेटिंग को साफ़ करती है और CODE_SIGNING_ALLOWED को NO पर सेट करती है। विशेष रूप से प्रभावित गैर-निष्पादन योग्य संसाधन-बंडल लक्ष्यों के लिए, अंतिम संग्रहीत ऐप और ऐप स्टोर सबमिशन वर्कफ़्लो के विरुद्ध मान्य होने पर टारगेट-स्तरीय कोड साइनिंग को अक्षम करना एक लक्षित बिल्ड-सिस्टम वर्कअराउंड के रूप में कार्य करता है।

नीचे दी गई Ruby स्क्रिप्ट दर्शाती है कि आपके प्रोजेक्ट Podfile के भीतर इस स्कोप्ड ओवरराइड को कैसे लागू किया जाए:

# Podfile - संसाधन बंडल साइनिंग के लिए स्कोप्ड बिल्ड सेटिंग्स ओवरराइड
# इस post_install हुक को अपने प्रोजेक्ट Podfile के सबसे नीचे रखें

post_install do |installer|
  # हस्ताक्षर छूट की आवश्यकता वाले विशिष्ट टारगेट बंडल नामों को परिभाषित करें
  affected_bundle_targets = [
    'libOpoInstallSDK-OPPrivacy'
  ]

  installer.pods_project.targets.each do |target|
    next unless target.respond_to?(:product_type)
    next unless target.product_type == 'com.apple.product-type.bundle'
    next unless affected_bundle_targets.include?(target.name)

    target.build_configurations.each do |config|
      # कोड साइन पहचान साफ़ करें और नामित संसाधन बंडलों के लिए साइनिंग अक्षम करें
      config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
      config.build_settings['CODE_SIGN_IDENTITY'] = ''
    end
  end
end

Xcode आर्काइव और सिम्युलेटर बिल्ड टारगेट में CI/CD संगतता का सत्यापन

Podfile में स्कोप्ड बिल्ड हुक जोड़ने के बाद, Pods.xcodeproj पर अद्यतन कॉन्फ़िगरेशन लागू करने के लिए pod install निष्पादित करें। सिम्युलेटर बिल्ड में आमतौर पर डिवाइस आर्काइव की तुलना में कम प्रतिबंध 19कारी वितरण-हस्ताक्षर आवश्यकताएँ होती हैं, लेकिन इंजीनियरिंग टीमों को स्थानीय सिम्युलेटर रन, CI/CD स्वचालित परीक्षण रन, और Xcode रिलीज़ आर्काइव कॉन्फ़िगरेशन में प्रभावित टारगेट सेटिंग्स को अलग से मान्य करना चाहिए।

कोड साइनिंग सत्यापन के लिए डायग्नोस्टिक निरीक्षण कमांड

टारगेट बिल्ड सेटिंग्स और कोड साइनिंग पहचान का निरीक्षण करना

बिल्ड सर्वर पर आंतरायिक (intermittent) साइनिंग विफलता का निदान करते समय, डेवलपर टर्मिनल कमांड के माध्यम से सीधे Xcode की बिल्ड कॉन्फ़िगरेशन की क्वेरी कर सकते हैं। यह सत्यापित करने की अनुमति देता है कि क्या Podfile post_install हुक ने प्रभावित उप-लक्ष्यों के लिए कोड साइनिंग आवश्यकताओं को सफलतापूर्वक साफ़ किया है। ध्यान दें कि टारगेट-विशिष्ट प्रभावी मानों को सत्यापित करने के लिए Xcode में Pods.xcodeproj के भीतर व्यक्तिगत लक्ष्यों पर सीधे बिल्ड सेटिंग्स का भी निरीक्षण किया जा सकता है।

प्रोजेक्ट रूट निर्देशिका से निम्नलिखित कमांड चलाएँ:

# किसी टारगेट वर्कस्पेस के लिए कोड साइनिंग बिल्ड सेटिंग्स का निरीक्षण करें
xcodebuild \
  -workspace YourApp.xcworkspace \
  -scheme YourApp \
  -configuration Release \
  -showBuildSettings | grep -E "(CODE_SIGN|DEVELOPMENT_TEAM)"

Xcode आर्काइव बंडलों और हस्ताक्षर अखंडता (Signature Integrity) का ऑडिट करना

आर्काइव निर्माण के बाद, यह पुष्टि करने के लिए संकलित एप्लिकेशन पैकेज का निरीक्षण करें कि गोपनीयता मेनिफेस्ट सही ढंग से स्थित हैं और फ्रेमवर्क बाइनरी हस्ताक्षर अखंडता बनाए रखते हैं।

एक निकाले गए IPA (Payload/YourApp.app के भीतर) या Xcode .xcarchive पथ (Products/Applications/YourApp.app) के भीतर इन डायग्नोस्टिक टर्मिनल कमांड को निष्पादित करें:

# निकाले गए IPA पैकेज के अंदर गोपनीयता मेनिफेस्ट की उपस्थिति का निरीक्षण करें
find Payload/YourApp.app -name "PrivacyInfo.xcprivacy" -print

# गतिशील रूप से एम्बेडेड फ्रेमवर्क के लिए, codesign हस्ताक्षर अखंडता सत्यापित करें:
codesign -dv --verbose=4 Payload/YourApp.app/Frameworks/OpoInstallSDK.framework

# अंतिम संकलित एप्लिकेशन बंडल पर गहरा हस्ताक्षर सत्यापन निष्पादित करें
# नोट: सत्यापन निरीक्षण के लिए सख्ती से --deep का उपयोग करें; कोड साइनिंग निष्पादन के दौरान --deep का उपयोग न करें
codesign --verify --deep --strict --verbose=2 Payload/YourApp.app

यह निरीक्षण अनुक्रम निष्पादित करना यह सुनिश्चित करने के लिए एक पूर्ण डायग्नोस्टिक लूप (पुनरुत्पादित करें → निरीक्षण करें → पैच करें → सत्यापित करें) स्थापित करता है कि रिलीज़ बिल्ड ऐप स्टोर कनेक्ट सत्यापन को संतुष्ट करते हैं।

CocoaPods निर्भरता प्रबंधक के माध्यम से iOS SDK कैसे आयात करें

pod ‘libOpoInstallSDK’ के साथ टारगेट प्रोजेक्ट Podfile को कॉन्फ़िगर करना

CocoaPods के माध्यम से ओपोइंस्टॉल (OpoInstall), एक मोबाइल एट्रिब्यूशन और डीप लिंकिंग प्लेटफॉर्म को एकीकृत करना, iOS ऐप के लिए मानक निर्भरता प्रबंधन दृष्टिकोण का प्रतिनिधित्व करता है। वर्तमान CocoaPods वितरण अपने पॉडस्पेक के अनुसार SDK के लिंकेज और पैक किए गए संसाधनों को संभालता है। जब SDK के वर्तमान CocoaPods एकीकरण या प्रोजेक्ट आर्किटेक्चर द्वारा आवश्यक हो तो use_frameworks! शामिल करें।

निर्भरता जोड़ने के लिए, रूट Podfile खोलें और टारगेट निर्भरता निर्दिष्ट करें:

target 'YourAppTarget' do
  use_frameworks!
  
  # OpoInstall iOS एट्रिब्यूशन SDK आयात करें
  pod 'libOpoInstallSDK'
end

निर्भरता अंतर्ग्रहण (Ingestion) निष्पादित करना और वर्कस्पेस अखंडता को सत्यापित करना

टर्मिनल का उपयोग करके प्रोजेक्ट रूट निर्देशिका से इंस्टॉलेशन कमांड चलाएँ:

pod install --repo-update

सफलतापूर्वक पूरा होने पर, CocoaPods .xcworkspace फ़ाइल को जनरेट या अपडेट करता है। डेवलपर्स को मानक .xcodeproj फ़ाइल बंद करनी होगी और Xcode में .xcworkspace फ़ाइल खोलनी होगी। यह सत्यापित करने के लिए कि libOpoInstallSDK और इसका संबंधित OPPrivacy बंडल टारगेट पॉड्स टारगेट सूची के अंतर्गत दिखाई देते हैं, Pods प्रोजेक्ट फ़ोल्डर का निरीक्षण करें।

Swift प्रोजेक्ट आर्किटेक्चर में SDK इंजन को आरंभ करना

फ्रेमवर्क को लिंक करने के बाद, एप्लिकेशन लाइफसाइकिल डेलिगेट के भीतर SDK को आरंभ करें। सटीक SDK रिलीज़ के लिए प्रलेखित लाइफसाइकिल बिंदु पर SDK को आरंभ करें; वर्तमान सार्वजनिक उदाहरण कोल्ड-स्टार्ट यूनिवर्सल लिंक पैरामीटर और गतिशील स्थापना पेलोड को कैप्चर करने के लिए इसे application(_:didFinishLaunchingWithOptions:) से आरंभ करते हैं। भेजे गए सटीक OpoInstall SDK संस्करण के विरुद्ध डेलिगेट प्रोटोकॉल और डेटा मॉडल प्रकार के नामों (जैसे, OpoinstallData या OpoInstallData) को सत्यापित करें।

डेवलपर विस्तृत डेलिगेट विधि परिभाषाओं और गतिशील पैरामीटर कॉलबैक हस्ताक्षरों के लिए संपूर्ण iOS एट्रिब्यूशन SDK दस्तावेज़ की समीक्षा कर सकते हैं।

नीचे दिया गया कार्यान्वयन स्निपेट यह दर्शाता है कि आधुनिक Swift कोडबेस में OpoInstallDelegate के अनुरूप कैसे होना चाहिए और SDK आरंभीकरण को कैसे ट्रिगर करना चाहिए:

// AppDelegate.swift - OpoInstall iOS SDK आरंभीकरण
// अपने iOS एप्लिकेशन डेलिगेट के अंदर रखें

import UIKit
import libOpoInstallSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // डेलिगेट श्रोता (listener) के साथ OpoInstall SDK आरंभ करें
        OpoInstallSDK.initWith(self)
        
        return true
    }

    // कॉलबैक विधि: डीप लिंक के माध्यम से ऐप लॉन्च होने पर पुनर्प्राप्त पैरामीटर संभालती है
    func getWakeUpParams(_ appData: OpoinstallData?) {
        if let customData = appData?.data {
            print("OpoInstall SDK: Custom Launch Parameters = \(customData)")
        }
        if let channelCode = appData?.channelCode {
            print("OpoInstall SDK: Channel ID = \(channelCode)")
        }
    }
}

iOS प्रोजेक्ट टारगेट के लिए मैन्युअल फ्रेमवर्क आयात वर्कफ़्लो

एंटरप्राइज बिल्ड वातावरण में CocoaPods पर मैन्युअल आयात कब चुनें

जबकि CocoaPods पैकेज प्रबंधन को सरल बनाता है, कुछ एंटरप्राइज विकास वातावरण कड़े सुरक्षा या बिल्ड वातावरण बाधाओं को लागू करते हैं। मैन्युअल फ्रेमवर्क एकीकरण तब पसंद किया जाता है जब:

• रिपॉजिटरी आइसोलेशन: बिल्ड सिस्टम आउटबाउंड इंटरनेट कनेक्शन को प्रतिबंधित करते हैं, जिससे संकलन के दौरान pod install निर्भरता फ़ेच रुक जाती है।
• बिल्ड पाइपलाइन गति: CocoaPods विश्लेषण और स्क्रिप्ट निष्पादन चरणों को समाप्त करने से CI/CD संकलन समय कम हो जाता है।
• प्रत्यक्ष बाइनरी नियंत्रण: सुरक्षा अनुपालन नीतियों के लिए प्रोजेक्ट में शामिल करने से पहले सटीक .xcframework कलाकृतियों पर स्थिर बाइनरी विश्लेषण की आवश्यकता होती है।

XCFramework कलाकृतियों को डाउनलोड करना और एम्बेड करना

निर्भरता प्रबंधकों के बिना SDK को मैन्युअल रूप से आयात करने के लिए, नवीनतम iOS SDK फ्रेमवर्क पैकेज डाउनलोड करें। संकलित OpoInstallSDK.xcframework निर्देशिका का पता लगाने के लिए वितरण आर्काइव को अनपैक करें।

यह पहचानने के लिए कि एम्बेड करने से पहले XCFramework स्लाइस स्टैटिक है या डायनेमिक, टर्मिनल में file कमांड निष्पादित करें:

# बाइनरी आर्किटेक्चर स्लाइस प्रकार की क्वेरी करें
file OpoInstallSDK.xcframework/ios-arm64/OpoInstallSDK.framework/OpoInstallSDK

बाइनरी को Xcode में एकीकृत करने के लिए इन चरणों का पालन करें:

• चरण 1: Xcode में अपना मुख्य एप्लिकेशन प्रोजेक्ट खोलें।
• चरण 2: प्राथमिक टारगेट फ्रेमवर्क समूह के अंतर्गत OpoInstallSDK.xcframework निर्देशिका को Xcode प्रोजेक्ट नेविगेटर में खींचें।
• चरण 3: संवाद संकेत में, Copy items if needed को चेक करें और Add to targets के अंतर्गत अपने प्राथमिक एप्लिकेशन टारगेट का चयन करें।

लाइब्ररीज और फ्रेमवर्क सर्च पाथ के साथ लिंक बाइनरी को कॉन्फ़िगर करना

Xcode के भीतर अपने एप्लिकेशन के टारगेट कॉन्फ़िगरेशन पर जाएँ:

• Build Phases: Link Binary With Libraries अनुभाग का विस्तार करें। पुष्टि करें कि OpoInstallSDK.xcframework सूचीबद्ध है।
• Build Settings: Framework Search Paths (FRAMEWORK_SEARCH_PATHS) खोजें। सुनिश्चित करें कि मैन्युअल रूप से जोड़े गए फ्रेमवर्क वाली निर्देशिका का पथ मौजूद है।
• System Dependencies: केवल उन Apple सिस्टम फ्रेमवर्क को जोड़ें जो आपके द्वारा एकीकृत किए जा रहे सटीक SDK रिलीज़ द्वारा प्रलेखित हैं (जैसे, AdSupport.framework या WebKit.framework)। असत्यापित लेगेसी फ्रेमवर्क न जोड़ें।

डायनेमिक बनाम स्टैटिक बाइनरी के लिए एम्बेड और साइन नीतियों को सेट करना

एप्लिकेशन टारगेट का चयन करें और General टैब पर जाएँ। Frameworks, Libraries, and Embedded Content अनुभाग का पता लगाएँ:

• डायनेमिक फ्रेमवर्क: एम्बेड विकल्प को Embed & Sign पर सेट करें। डायनेमिक फ्रेमवर्क को अंतिम ऐप बंडल की Frameworks निर्देशिका के भीतर रहना चाहिए ताकि डायनेमिक लिंकर (dyld) रनटाइम पर उन्हें लोड कर सके, और Xcode आर्काइविंग के दौरान आपकी डेवलपमेंट टीम का कोड हस्ताक्षर लागू करेगा।
• संसाधनों के बिना स्टैटिक फ्रेमवर्क: बाइनरी को लिंक करना पर्याप्त है, और फ्रेमवर्क को एम्बेड करना आम तौर पर अनावश्यक है क्योंकि स्टैटिक कोड सीधे मुख्य एप्लिकेशन निष्पादन योग्य (executable) में संकलित होता है।
• संसाधनों के साथ स्टैटिक फ्रेमवर्क (गोपनीयता मेनिफेस्ट सहित): SDK विक्रेता के वितरण दिशानिर्देशों का पालन करें। एम्बेडेड संसाधनों को पैकेज करने के लिए निर्मित Xcode 15+ स्टैटिक फ्रेमवर्क के लिए, Apple Embed & Sign के साथ फ्रेमवर्क जोड़ने का दस्तावेजीकरण करता है; Xcode फ्रेमवर्क बंडल और उसके एम्बेडेड संसाधनों को संरक्षित और हस्ताक्षरित करते हुए पहले से ही स्टैटिक रूप से जुड़े निष्पादन योग्य बाइनरी को छोड़ देता है।

CocoaPods में PrivacyInfo.xcprivacy हस्ताक्षर संघर्षों का निवारण (Troubleshooting)

तृतीय-पक्ष फ्रेमवर्क निर्भरता के लिए Apple गोपनीयता मेनिफेस्ट आवश्यकताएँ

तृतीय-पक्ष SDK को उनके API उपयोग, डेटा-संग्रह प्रथाओं, ट्रैकिंग व्यवहार और इस बात के आधार पर कि क्या SDK स्पष्ट मेनिफेस्ट आवश्यकताओं के अधीन SDK की Apple की प्रकाशित सूची में दिखाई देता है, PrivacyInfo.xcprivacy मेनिफेस्ट शामिल करने की आवश्यकता हो सकती है।

वर्तमान OpoInstall वितरण में एक PrivacyInfo.xcprivacy मेनिफेस्ट शामिल है; डेवलपर्स को आर्काइव करने से पहले भेजे गए विशिष्ट SDK संस्करण और Apple के वर्तमान सबमिशन दिशानिर्देशों के विरुद्ध इसकी घोषणाओं को सत्यापित करना चाहिए।

डुप्लिकेट गोपनीयता मेनिफेस्ट संसाधन संघर्षों को हल करना

एक ऐसा एप्लिकेशन बनाते समय जो कई तृतीय-पक्ष निर्भरता को शामिल करता है, Xcode संग्रहीत ऐप और लिंक किए गए SDK बंडलों में गोपनीयता मेनिफेस्ट की खोज करता है, शामिल गोपनीयता घोषणाओं का ऑडिट करने के लिए Xcode गोपनीयता रिपोर्ट जनरेट करते समय उनकी घोषणाओं को एकत्रित करता है।

यदि कोई प्रोजेक्ट मुख्य टारगेट के Copy Bundle Resources चरण के ठीक अंदर गलती से डुप्लिकेट गोपनीयता मेनिफेस्ट फ़ाइलों को शामिल करता है, तो Xcode एक बिल्ड चेतावनी या त्रुटि उत्सर्जित कर सकता है:

Multiple commands produce '.../PrivacyInfo.xcprivacy'

इस संघर्ष को हल करने के लिए:

• फ्रेमवर्क मेनिफेस्ट स्थान: एक iOS XCFramework के लिए, PrivacyInfo.xcprivacy को प्रत्येक लागू प्लेटफ़ॉर्म-विशिष्ट फ्रेमवर्क संस्करण के अंदर रहना चाहिए (उदाहरण के लिए, OpoInstallSDK.xcframework/ios-arm64/OpoInstallSDK.framework/PrivacyInfo.xcprivacy), न कि XCFramework रूट कंटेनर निर्देशिका पर रखा जाना चाहिए।
• मुख्य ऐप संसाधन: SDK फ्रेमवर्क वेरिएंट को आंतरिक रूप से अपने संबंधित मेनिफेस्ट फ़ाइलों को प्रबंधित करने की अनुमति देते हुए, होस्ट एप्लिकेशन गोपनीयता घोषणाओं को मुख्य टारगेट के संसाधनों में रखें।

PrivacyInfo.xcprivacy के अंदर आवश्यक कारण (Required Reason) API घोषणाओं को सत्यापित करना

यह सत्यापित करने के लिए कि सभी घोषित API श्रेणियाँ Apple के आधिकारिक आवश्यक कारण API विनिर्देशों से मेल खाती हैं, गोपनीयता मेनिफेस्ट की सामग्री का निरीक्षण करें। Xcode में संपत्ति सूची (Property List) या कच्चे XML के रूप में PrivacyInfo.xcprivacy खोलें। घोषणाएँ आवश्यक API उपयोगों के अनुरूप होनी चाहिए:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

केवल उन API श्रेणियों और स्वीकृत कारण कोड को शामिल करें जो SDK की वास्तविक कार्यान्वयन आवश्यकताओं के अनुरूप हैं।

अंतिम ऐप स्टोर कनेक्ट IPA सबमिशन को सत्यापित करना

ऐप स्टोर कनेक्ट में एप्लिकेशन अपडेट सबमिट करने से पहले, संकलित IPA आर्काइव को स्थानीय रूप से सत्यापित करें:

• चरण 1: Xcode में, Product > Archive चुनें।
• चरण 2: आर्काइव पूरा होने पर, Organizer विंडो के भीतर Validate App पर क्लिक करें।
• चरण 3: Xcode Apple सत्यापन सर्वर के विरुद्ध एम्बेडेड फ्रेमवर्क हस्ताक्षर, प्रोविजनिंग हक़ (entitlements), और गोपनीयता मेनिफेस्ट स्कीमा की जाँच करता है।

एक सफल सत्यापन इंगित करता है कि आर्काइव ने उस पूर्व-सबमिशन सत्यापन चरण को साफ़ कर लिया है; यह TestFlight या उत्पादन सबमिशन से पहले एक आवश्यक बिल्ड सत्यापन चरण के रूप में कार्य करता है।

CocoaPods बनाम मैन्युअल iOS फ्रेमवर्क आयात का तुलनात्मक विश्लेषण

CocoaPods और मैन्युअल फ्रेमवर्क एकीकरण के बीच चयन करने में टीम वर्कफ़्लो, बिल्ड सर्वर क्षमताओं और निर्भरता रखरखाव ओवरहेड का मूल्यांकन करना शामिल है। जबकि CocoaPods संस्करण अपडेट को स्वचालित करता है, Xcode संस्करण अपग्रेड के लिए Apple की बदलती हस्ताक्षर नीतियों से मेल खाने के लिए Podfile post_install हुक को अपडेट करने की आवश्यकता हो सकती है।

नीचे दी गई तालिका दोनों आयात रणनीतियों की विस्तृत तकनीकी तुलना प्रदान करती है:

एंटरप्राइज मोबाइल टीमों में निर्भरता प्रबंधन रणनीतियों का मूल्यांकन

CocoaPods उन टीमों के लिए एक व्यावहारिक विकल्प बना हुआ है जो Podfile.lock के माध्यम से स्वचालित निर्भरता समाधान और केंद्रीकृत संस्करण लिंकिंग के कारण Podfile-आधारित निर्भरता प्रबंधन पर पहले से ही मानक हैं। एक स्कोप्ड Ruby हस्ताक्षर ओवरराइड स्क्रिप्ट को शामिल करने से टीम के वर्कस्टेशन और CI/CD बिल्ड वातावरण में टारगेट-स्तरीय साइनिंग अवरोधों को दूर करने में मदद मिलती है।

सारांश और निर्णय फ्रेमवर्क

iOS SDK को कुशलतापूर्वक आयात करने के लिए Xcode कोड साइनिंग कठोरता को कम करते हुए आपके प्रोजेक्ट टूलचैन के लिए उपयुक्त निर्भरता तंत्र का चयन करने की आवश्यकता होती है। एक स्कोप्ड post_install हुक के साथ CocoaPods का उपयोग करने से प्रभावित संसाधन-बंडल साइनिंग विफलता हल हो सकती है, जबकि मैन्युअल XCFramework एम्बेडिंग बिल्ड कलाकृतियों पर सीधा नियंत्रण प्रदान करता है।

चूँकि Apple ऐप स्टोर कनेक्ट सत्यापन नियमों को परिष्कृत करना जारी रखता है, क्लाइंट निर्भरता को गोपनीयता मेनिफेस्ट मानकों के अनुरूप रखना महत्वपूर्ण बना हुआ है। अद्यतन SDK संस्करणों को तैनात करके और स्वचालित Podfile हुक बनाए रखकर, इंजीनियरिंग टीम आवर्ती बिल्ड अवरोधों को कम करती हैं और एकीकरण स्थिरता में सुधार करती हैं।

अपने प्रोजेक्ट कुंजी को आरंभ करने के लिए तैयार डेवलपर OpoInstall डेवलपर कंसोल पर पंजीकरण कर सकते हैं या अतिरिक्त प्लेटफ़ॉर्म दिशानिर्देशों के लिए संपूर्ण मोबाइल एट्रिब्यूशन कार्यान्वयन संदर्भ की समीक्षा कर सकते हैं।

संबंधित सामग्रियां

• अवधारणाएँ: iOS SDK, कोड साइनिंग आइडेंटिटी, रिसोर्स बंडल साइनिंग, प्राइवेसी मेनिफेस्ट एग्रीगेशन

• प्रौद्योगिकियाँ: CocoaPods, Xcode बिल्ड टूल्स, XCFramework, Swift पैकेज मैनेजर

• मानक: Apple ऐप स्टोर कनेक्ट सबमिशन दिशानिर्देश, Apple प्राइवेसी मेनिफेस्ट आवश्यकताएँ

• APIs: OpoInstall iOS SDK डेलिगेट APIs, Apple UIPasteboard APIs, यूनिवर्सल लिंक्स एसोसिएटेड डोमेन APIs

• आधिकारिक दस्तावेज़ और संदर्भ:

  • प्राइवेसी मेनिफेस्ट फाइलों पर Apple डेवलपर मार्गदर्शन

  • तृतीय-पक्ष SDK आवश्यकताओं पर Apple दस्तावेज़

  • आवश्यक कारण API पर Apple डेवलपर तकनीकी नोट

  • स्टैटिक फ्रेमवर्क बनाने पर Apple Xcode मार्गदर्शन

  • Podfile हुक के लिए CocoaPods सिंटैक्स संदर्भ