मोबाइल एट्रिब्यूशन और ग्रोथ को संचालित करने वाले सॉफ्टवेयर डेवलपमेंट किट्स

SDK क्या है और यह कैसे काम करता है? सॉफ्टवेयर डेवलपमेंट किट (SDK) लाइब्रेरी, API, टूल्स और दस्तावेज़ों का एक ऐसा संग्रह है जो डेवलपर्स को सॉफ्टवेयर एप्लिकेशन बनाने या उनका विस्तार करने में मदद करने के लिए डिज़ाइन किया गया है। मोबाइल डेवलपमेंट में, एक SDK में आमतौर पर डीप लिंक्स और एट्रिब्यूशन जैसी प्लेटफ़ॉर्म-विशिष्ट कार्यक्षमता प्रदान करने के लिए नेटिव एप्लिकेशन में एकीकृत संकलित (compiled) लाइब्रेरी शामिल होती हैं। जब मोबाइल इंजीनियरिंग टीमें यह मूल्यांकन करती हैं कि यूजर अधिग्रहण डेटा किसी वेब प्रमोशन से नए इंस्टॉल किए गए एप्लिकेशन में कैसे प्रवाहित होता है, तो उन्हें एक बुनियादी ऑपरेटिंग सिस्टम सीमा का सामना करना पड़ता है: रिमोट वेब इंटरफेस अकेले नेटिव एप्लिकेशन लाइफ़साइकिल तक नहीं पहुंच सकते हैं या ऐप स्टोर सैंडबॉक्स को पार नहीं कर सकते हैं। OpoInstall, एक मोबाइल एट्रिब्यूशन और डीप लिंकिंग प्लेटफ़ॉर्म है, जो कैंपेन पैरामीटर्स को पुनर्स्थापित करने और उपयोगकर्ताओं को लक्षित इन-ऐप व्यू पर रूट करने के लिए इन पृथक्कृत वातावरणों में समन्वय करने वाली नेटिव क्लाइंट लाइब्रेरी और वेब स्क्रिप्ट प्रदान करता है।

सॉफ्टवेयर डेवलपमेंट किट (SDK) किसी विशिष्ट ऑपरेटिंग सिस्टम या फ्रेमवर्क के लिए डिज़ाइन की गई लाइब्रेरी, एप्लिकेशन प्रोग्रामिंग इंटरफेस (API), हेडर फ़ाइलें, डेवलपर दस्तावेज़ और नमूना कोड का एक पूर्व-पैकेज्ड संग्रह है। एक स्टैंडअलोन रिमोट वेब API के विपरीत जो HTTP पर स्टेटलेस संचार इंटरफेस को परिभाषित करता है, एक मोबाइल SDK स्थानीय स्थिति, ऑपरेटिंग सिस्टम लाइफ़साइकिल कॉलबैक और अतुल्यकालिक (asynchronous) नेटवर्क टेलीमेट्री को प्रबंधित करने के लिए सीधे क्लाइंट एप्लिकेशन की रनटाइम प्रक्रिया के भीतर निष्पादित होता है।

SDK क्या है और यह मानक वेब API से किस प्रकार भिन्न है

शब्दावली को समझना: प्रत्येक SDK में API क्यों होते हैं, लेकिन एक API, SDK क्यों नहीं है

सॉफ्टवेयर इंजीनियरिंग में, मोबाइल ग्रोथ बुनियादी ढांचे से नए जुड़े डेवलपर्स अक्सर एप्लिकेशन प्रोग्रामिंग इंटरफेस (API) को सॉफ्टवेयर डेवलपमेंट किट (SDK) के साथ भ्रमित कर देते हैं। हालांकि दोनों अवधारणाएं एक साथ काम करती हैं, लेकिन वे सॉफ्टवेयर आर्किटेक्चर की अलग-अलग परतों पर कार्य करती हैं।

एक API कड़ाई से एक इंटरफेस विनिर्देश और संचार अनुबंध है। यह IETF RFC 3986 के अनुसार मेथड सिग्नचर, डेटा संरचनाओं, URI सिंटैक्स और प्रतिक्रिया प्रारूपों को परिभाषित करता है जो एक सॉफ्टवेयर घटक को दूसरे के साथ बातचीत करने की अनुमति देते हैं। API कई स्तरों पर मौजूद होते हैं: वे स्थानीय ऑपरेटिंग सिस्टम इंटरफेस, इन-प्रक्रिया लाइब्रेरी इंटरफेस, या IETF RFC 9110 HTTP सिमेंटिक्स (GET, POST) द्वारा नियंत्रित रिमोट स्टेटलेस वेब एंडपॉइंट हो सकते हैं। जब किसी रिमोट REST API को सीधे कॉल किया जाता है, तो एप्लिकेशन डेवलपर को नेटवर्क अनुरोध का निर्माण करना होगा, ट्रांसपोर्ट सुरक्षा का प्रबंधन करना होगा, लौटाए गए JSON पेलोड को पार्स करना होगा, और पुनः प्रयास की स्थितियों को मैन्युअल रूप से संभालना होगा।

इसके विपरीत, एक SDK, पूर्ण कार्यान्वयन किट है जो रनटाइम लॉजिक, दस्तावेज़ और डेवलपर टूलिंग के साथ एक या अधिक स्थानीय API को एनकैप्सुलेट करती है। जब कोई डेवलपर Android Studio या Xcode प्रोजेक्ट में मोबाइल SDK आयात करता है, तो वे प्री-बिल्ट लाइब्रेरी कोड को सीधे अपने एप्लिकेशन बाइनरी से जोड़ते हैं। SDK होस्ट एप्लिकेशन को स्थानीय प्रोग्रामेटिक API (जैसे initialize(), getInstallParam(), या handleDeepLink()) प्रदान करता है, जबकि आंतरिक रूप से थ्रेड शेड्यूलिंग, ऑपरेटिंग सिस्टम कॉलबैक और रिमोट सर्वर संचार का प्रबंधन करता है।

निष्पादन संदर्भ: स्टेटलेस सर्वर-से-सर्वर एंडपॉइंट्स बनाम स्टेटफुल क्लाइंट-साइड रनटाइम लाइब्रेरीज़

रिमोट वेब API को कॉल करने और नेटिव मोबाइल SDK को एकीकृत करने के बीच परिचालन अंतर निष्पादन संदर्भ और डिवाइस वातावरण तक पहुंच पर केंद्रित है:

• प्रक्रिया निवास और पैकेजिंग: एक रिमोट वेब API को सर्वर-साइड बुनियादी ढांचे के माध्यम से प्रदर्शित किया जाता है और नेटवर्क पर आह्वान किया जाता है; सर्वर-side एप्लिकेशन एंडपॉइंट को लागू करता है, जबकि क्लाइंट एप्लिकेशन अनुरोध-हैंडलिंग लॉजिक को निष्पादित करता है। इसके विपरीत, एक मोबाइल SDK को एप्लिकेशन के प्रकाशन कलाकृति (जैसे एंड्रॉइड ऐप बंडल .aab) या इंस्टॉल करने योग्य एप्लिकेशन पैकेज (एंड्रॉइड पर .apk और iOS पर .ipa) में संकलित किया जाता है और अंत उपयोगकर्ता के डिवाइस पर एप्लिकेशन की आवंटित मेमोरी स्पेस के अंदर निष्पादित होता है।
• नेटिव लाइफ़साइकिल जागरूकता: रिमोट REST एंडपॉइंट तभी प्रतिक्रिया देते हैं जब कोई क्लाइंट HTTP अनुरोध प्रेषित करता है। एक नेटिव मोबाइल SDK मोबाइल ऑपरेटिंग सिस्टम के साथ ऑब्ज़र्वर को पंजीकृत करता है, जिससे यह पता चलता है कि एप्लिकेशन कब लॉन्च होता है, फोरग्राउंड और बैकग्राउंड स्थितियों के बीच转换 करता है, या सिस्टम-स्तरीय रूटिंग उद्देश्य प्राप्त करता है।
• वैकल्पिक स्थानीय दृढ़ता और कतारबद्ध करना: अपने कार्यान्वयन के आधार पर, एक मोबाइल SDK स्थानीय सैंडबॉक्स स्टोरेज (जैसे एंड्रॉइड पर SharedPreferences या SQLite, और iOS पर UserDefaults या एप्लिकेशन फ़ाइल स्टोरेज में, जबकि छोटे संवेदनशील क्रेडेंशियल्स के लिए Keychain आरक्षित रखता है) में कॉन्फ़िगरेशन स्थिति को संग्रहीत कर सकता है या रूपांतरण घटनाओं को कतारबद्ध कर सकता है ताकि नेटवर्क कनेक्टिविटी उपलब्ध होने पर टेलीमेट्री को अतुल्यकालिक रूप से प्रेषित किया जा सके।

आर्किटेक्चरल तुलना: रिमोट वेब API बनाम नेटिव मोबाइल SDKs

नीचे दी गई तालिका मुख्य आर्किटेक्चरल आयामों में रिमोट स्टेटलेस वेब API और संकलित नेटिव मोबाइल SDKs की तुलना करती है:

मोबाइल सॉफ्टवेयर डेवलपमेंट किट के अंदर के मुख्य घटक

संकलित बाइनरी लाइब्रेरीज़: एंड्रॉइड आर्काइव बंडल्स और iOS फ्रेमवर्क

मोबाइल SDK के मूल में लक्षित ऑपरेटिंग सिस्टम के बिल्ड टूलचेन के लिए स्वरूपित एक संकलित बाइनरी वितरण होता है:

• एंड्रॉइड आर्काइव (.aar), JAR और ऐप बंडल्स (.aab): एंड्रॉइड पर, SDK को .aar बंडल्स या .jar लाइब्रेरीज़ के रूप में वितरित किया जाता है। जबकि एक .jar फ़ाइल में संकलित JVM बाइटकोड होता है, एक .aar बंडल एंड्रॉइड-विशिष्ट संसाधनों और मैनिफेस्ट प्रविष्टियों को भी पैक कर सकता है जो Gradle बिल्ड के दौरान होस्ट एप्लिकेशन में विलीन हो जाते हैं। जब होस्ट एप्लिकेशन को रिलीज़ के लिए बनाया जाता है, तो एंड्रॉइड ऐप बंडल (.aab) सीधे इंस्टॉल करने योग्य एप्लिकेशन पैकेज के बजाय प्रकाशन कलाकृति के रूप में कार्य करता है; Google Play इसे डिवाइस-विशिष्ट APK में संसाधित करता है जो उपयोगकर्ताओं को वितरित किए जाते हैं।
• iOS स्टैटिक लाइब्रेरीज़ (.a), फ्रेमवर्क और XCFrameworks: iOS पर, SDK को स्टैटिक लाइब्रेरीज़, .framework बंडल्स या .xcframework आर्काइव के रूप में वितरित किया जाता है। एक मानक .framework बिल्ड आमतौर पर किसी विशिष्ट प्लेटफ़ॉर्म संस्करण को लक्षित करता है और इसमें एक या अधिक समर्थित CPU आर्किटेक्चर हो सकते हैं, जबकि एक Apple XCFramework (.xcframework) बंडल को कई प्लेटफ़ॉर्म और आर्किटेक्चर वेरिएंट—जैसे भौतिक ARM64 iOS डिवाइस स्लाइस और iOS सिम्युलेटर स्लाइस—को एक एकल वितरणीय कलाकृति में पैक करने के लिए डिज़ाइन किया गया है।

सार्वजनिक हेडर फ़ाइलें, इंटरफेस अनुबंध और टाइप परिभाषाएँ

संकलित बाइनरी को सार्वजनिक टाइप अनुबंधों की आवश्यकता होती है ताकि होस्ट एप्लिकेशन का कंपाइलर बिल्ड समय पर मेथड कॉल को सत्यापित कर सके:

• iOS हेडर फ़ाइलें (.h) और ब्रिजिंग इंटरफेस: Objective-C आधारित iOS SDK सार्वजनिक हेडर फ़ाइलें (जैसे OpoInstallSDK.h) प्रदान करते हैं जो क्लास इंटरफेस, डेलिगेट प्रोटोकॉल (OpoInstallDelegate) और डेटा मॉडल (OpoinstallData) की घोषणा करते हैं। Swift प्रोजेक्ट्स में, इन घोषणाओं को Objective-C ब्रिजिंग हेडर या मॉड्यूल आयात के माध्यम से प्रदर्शित किया जाता है।
• एंड्रॉइड क्लास सिग्नेचर और कॉलबैक इंटरफेस: एंड्रॉइड SDK प्रलेखित पैकेज नेमस्पेस के भीतर सार्वजनिक एंट्री-पॉइंट क्लास और सामान्य कॉलबैक इंटरफेस (जैसे ResultCallBack<OpoData>) को उजागर करते हैं।

कॉन्फ़िगरेशन मैनिफेस्ट, AppKeys और एंटाइटेलमेंट घोषणाएँ

एक मोबाइल SDK टेनेंट अनुरोधों को प्रमाणित करने और OS रूटिंग हुक को पंजीकृत करने के लिए होस्ट कॉन्फ़िगरेशन मेटाडेटा पर निर्भर करता है:

• टेनेंट एप्लिकेशन आइडेंटिफ़ायर (AppKey): एंड्रॉइड AndroidManifest.xml <meta-data> टैग या iOS Info.plist फ़ाइल (com.opoinstall.APP_KEY) के अंदर घोषित, AppKey SDK आरंभीकरण के दौरान एप्लिकेशन टेनेंट की पहचान करता है।
• OS रूटिंग घोषणाएँ: वन-क्लिक ऐप लॉन्च का समर्थन करने के लिए, होस्ट प्रोजेक्ट कस्टम URL स्कीमें और सत्यापित डोमेन एसोसिएशन (Xcode एसोसिएटेड डोमेन एंटाइटेलमेंट में applinks: डोमेन और एंड्रॉइड पर सत्यापित इंटेंट फ़िल्टर) घोषित करता है।

दस्तावेज़ और नमूना प्रोजेक्ट्स: संकलित लाइब्रेरीज़ को उपयोग योग्य डेवलपर इंटरफेस में बदलना

स्पष्ट एकीकरण विशिष्टताओं के बिना संकलित लाइब्रेरी को अपनाना कठिन होता है। उत्पादन-ग्रेड SDK को स्पष्ट डेवलपर दस्तावेज़ और, जहां उपलब्ध हो, चलने योग्य नमूना प्रोजेक्ट प्रदान करने चाहिए:

• डेवलपर दस्तावेज़: संस्करण संगतता, लाइफ़साइकिल आरंभीकरण क्रम, आवश्यक अनुमतियाँ, कॉलबैक पेलोड प्रारूप और त्रुटि कोड को परिभाषित करता है ताकि इंजीनियर लाइब्रेरी को पूर्वानुमानित रूप से एकीकृत कर सकें।
• नमूना प्रोजेक्ट और क्रॉस-प्लेटफ़ॉर्म ब्रिज: न्यूनतम चलने योग्य डेमो प्रोजेक्ट टीमों को डीप लिंकिंग और पैरामीटर पुनर्स्थापना को सत्यापित करने में मदद करते हैं। जबकि मोबाइल SDK डाउनलोड सेंटर मुख्य रूप से कोर नेटिव एंड्रॉइड और iOS SDK पैकेजों (वर्तमान में v2.1.0) को वितरित करता है, क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क (जैसे Flutter या Unity) का उपयोग करने वाली टीमें रैपर प्लगइन या प्लेटफ़ॉर्म चैनलों के माध्यम से इन नेटिव SDK क्षमताओं को ब्रिज करती हैं और आधिकारिक दस्तावेजों के खिलाफ उपलब्ध प्लगइन रिपॉजिटरी को सत्यापित करना चाहिए।

वेब API अकेले मोबाइल इंस्टॉल एट्रिब्यूशन को क्यों हल नहीं कर सकते

ऐप स्टोर ब्लैक बॉक्स: सैंडबॉक्स आइसोलेशन पारंपरिक वेब कुकी ट्रैकिंग को कैसे तोड़ता है

मानक वेब डेवलपमेंट में, पंजीकरण इवेंट के लिए रेफ़रल लिंक को ट्रैक करना ब्राउज़र स्टोरेज पर निर्भर करता है: जब कोई उपयोगकर्ता https://example.com/index.html?inviter_id=A102 पर जाता है, तो JavaScript क्वेरी स्ट्रिंग को पढ़ता है और localStorage या HTTP कुकी में inviter_id=A102 को संग्रहीत करता है।

मोबाइल ऐप अधिग्रहण में, ऐप स्टोर सीमा पर यह निरंतरता टूट जाती है—एक संरचना जिसे ऐप स्टोर ब्लैक बॉक्स के रूप में जाना जाता है:

1. वेब संदर्भ: कोई उपयोगकर्ता मोबाइल ब्राउज़र या सोशल ऐप के अंदर एक प्रचार लिंक पर क्लिक करता है, जिससे कस्टम पैरामीटर (?ref=userA&channelCode=ch_01) ले जाने वाला एक H5 लैंडिंग पेज लोड होता है।
2. मार्केटप्लेस हैंडऑफ़: चूंकि नेटिव ऐप अभी तक इंस्टॉल नहीं हुआ है, इसलिए डाउनलोड बटन पर क्लिक करने से उपयोगकर्ता ब्राउज़र से बाहर निकलकर Apple App Store या Google Play Store में रीडायरेक्ट हो जाता है।
3. सैंडबॉक्स आइसोलेशन: जब उपयोगकर्ता नेटिव ऐप को इंस्टॉल और लॉन्च करता है, तो मोबाइल OS प्रक्रिया को एक पृथक्कृत फ़ाइल सिस्टम और मेमोरी सैंडबॉक्स के भीतर उत्पन्न करता है। नेटिव ऐप डाउनलोड शुरू करने वाले ब्राउज़र सत्र की कुकीज़ या localStorage को नहीं पढ़ सकता है।

वेब-टू-ऐप गैप को पाटना: वेब JS SDKs और नेटिव क्लाइंट SDKs की भूमिका

ऐप स्टोर सीमा पर पैरामीटर को हल करने के लिए एक समन्वित कार्यप्रवाह का उपयोग किया जाता है जो तीन संबंधित अवधारणाओं को अलग करता है—डिफर्ड डीप लिंकिंग (इंस्टॉलेशन के बाद किसी नए उपयोगकर्ता को लक्षित इन-ऐप स्क्रीन पर रूट करना), इंस्टॉल पैरामीटर रीस्टोरेशन (H5 लिंक पर पारित कस्टम की-वैल्यू जोड़े को पुनर्प्राप्त करना), और एट्रिब्यूशन मिलान (इंस्टॉल को किसी विशिष्ट प्रचार चैनल के साथ जोड़ना):

• प्री-इंस्टॉल वेब JS SDK (OpoInstall वेब स्क्रिप्ट): H5 लैंडिंग पेज में एकीकृत, वेब JS SDK शेयरिंग URL से गतिशील क्वेरी पैरामीटर (जैसे channelCode, shareCode, या रूम ID) को पार्स करता है और ऐप वेकअप या स्टोर रीडायरेक्ट को ट्रिगर करने से पहले एट्रिब्यूशन सर्वर पर प्री-इंस्टॉल सत्र संदर्भ अपलोड करता है।
• पोस्ट-इंस्टॉल नेटिव क्लाइंट SDK (एंड्रॉइड / iOS SDK): मोबाइल ऐप बाइनरी में एकीकृत, नेटिव SDK पहली लॉन्च पर आरंभ होता है, प्लेटफ़ॉर्म API और एट्रिब्यूशन सर्वर के साथ संचार करता है, और एक अतुल्यकालिक कॉलबैक के माध्यम से क्लाइंट ऐप को पुनर्स्थापित कस्टम पैरामीटर लौटाता है।

[मोबाइल वेब ब्राउज़र: H5 लैंडिंग पेज]
                 |
                 | 1. वेब JS SDK URL पैरामीटर पार्स करता है (?ref=userA&channelCode=ch01)
                 |    और प्री-इंस्टॉल सत्र संदर्भ अपलोड करता है
                 v
     [एट्रिब्यूशन सर्वर बैकएंड]
                 |
                 | 2. उपयोगकर्ता ऐप स्टोर / गूगल प्ले से ऐप डाउनलोड करता है
                 |    (ब्राउज़र कुकीज़ OS सैंडबॉक्स को पार नहीं कर सकती हैं)
                 v
   [नेटिव ऐप पहला लॉन्च: मोबाइल SDK]
                 |
                 | 3. क्लाइंट SDK स्टार्टअप पर आरंभ होता है और
                 |    कैश किए गए कस्टम पैरामीटर + चैनल ID पुनर्प्राप्त करता है
                 v
  [इन-ऐप रूटिंग और चैनल एट्रिब्यूशन]

प्लेटफ़ॉर्म-विशिष्ट एट्रिब्यूशन तंत्र: Google Play इंस्टॉल रेफ़रर बनाम iOS संदर्भ समाधान

चूंकि एंड्रॉइड और iOS अलग-अलग ऐप स्टोर आर्किटेक्चर बनाए रखते हैं, इसलिए मोबाइल एट्रिब्यूशन अलग-अलग प्लेटफ़ॉर्म तंत्रों पर निर्भर करता है:

• एंड्रॉइड इकोसिस्टम और Google Play इंस्टॉल रेफ़रर API: Google Play के माध्यम से वितरित ऐप्स के लिए, नेटिव एकीकरण इंस्टॉलेशन के दौरान Play Store द्वारा पारित रेफ़रल मेटाडेटा (रेफ़रर URL और क्लिक/इंस्टॉल टाइमस्टैम्प सहित) को पुनर्प्राप्त करने के लिए आधिकारिक Google Play Install Referrer API का उपयोग कर सकता है। चूंकि Google Play Install Referrer API विशेष रूप से योग्य Google Play Store इंस्टॉलेशन प्रवाह पर लागू होता है, इसलिए Google Play के बाहर एंड्रॉइड वितरण सर्वर-साइड H5 पैरामीटर मिलान या निर्यातित एंड्रॉइड चैनल पैकेजों (एम्बेडेड channelCode पहचानकर्ता ले जाने वाली APK फ़ाइलें) पर निर्भर करते हैं।
• iOS इकोसिस्टम और संदर्भ समाधान (Context Reconciliation): Apple का App Store Google Play के इंस्टॉल रेफ़रर के समतुल्य सामान्य URL क्वेरी-पैरामीटर पासथ्रू तंत्र प्रदान नहीं करता है। जब ऐप पहले से इंस्टॉल होता है, तो iOS उपयोगकर्ताओं को Apple Universal Links के माध्यम से सीधे ऐप में रूट करता है, जो apple-app-site-association (AASA) फ़ाइल के माध्यम से डोमेन स्वामित्व को सत्यापित करते हैं। जब ऐप इंस्टॉल नहीं होता है, तो यूनिवर्सल लिंक एक वेबसाइट पर वापस आते हैं और स्वतंत्र रूप से इंस्टॉल के बाद पैरामीटर पुनर्प्राप्ति की गारंटी नहीं देते हैं; डिफर्ड पैरामीटर पुनर्स्थापना के लिए पहले लॉन्च पर सर्वर-साइड सत्र समाधान की आवश्यकता होती है।

प्लेटफ़ॉर्म गोपनीयता सीमाओं का सम्मान करना: Apple उपयोगकर्ता गोपनीयता दिशानिर्देश और अनुमत मिलान संकेत

यह मूल्यांकन करते समय कि मोबाइल SDK प्री-इंस्टॉल वेब विज़िट को पोस्ट-इंस्टॉल लॉन्च के साथ कैसे मिलाते हैं, इंजीनियरिंग टीमों को विक्रेता-प्रलेखित सुविधाओं को ऑपरेटिंग सिस्टम नीति अनुपालन से अलग करना चाहिए:

• विक्रेता-प्रलेखित तंत्र: OpoInstall के सार्वजनिक उत्पाद दस्तावेज़ में एक H5 चैनल और पैरामीटर इंस्टॉलेशन कार्यप्रवाह का वर्णन किया गया है जहाँ वेब SDK H5 पेज पर डिवाइस फ़िंगरप्रिंट लक्षण और चैनल ID एकत्र करता है, और इंस्टॉलेशन स्रोत का मिलान करने के लिए नेटिव एंड्रॉइड/iOS SDK पहली लॉन्च पर डिवाइस लक्षणों को फिर से एकत्र करता है।
• Apple प्लेटफ़ॉर्म नीति सीमा: Apple के उपयोगकर्ता गोपनीयता और डेटा उपयोग दिशानिर्देशों के तहत, Apple किसी उपयोगकर्ता या डिवाइस की विशिष्ट रूप से पहचान करने के उद्देश्य से डिवाइस से डेटा प्राप्त करने—जैसे ब्राउज़र गुणों, IP पतों, या सिस्टम कॉन्फ़िगरेशन को संयोजित करना (फ़िंगरप्रिंटिंग)—स्पष्ट रूप से प्रतिबंधित करता है। प्रतिबंधित फ़िंगरप्रिंटिंग में शामिल होने वाले एप्लिकेशन, या ऐसा करने वाले तृतीय-पक्ष SDK का संदर्भ देने वाले एप्लिकेशन, ऐप स्टोर समीक्षा के दौरान अस्वीकृति का जोखिम उठाते हैं। अलग से, जब तृतीय-पक्ष डीप-लिंकिंग या डिफर्ड डीप-लिंकिंग सेवाएँ अद्वितीय पहचानकर्ता पारित करती हैं या विज्ञापन लक्ष्यीकरण, विज्ञापन माप, या डेटा-ब्रोकर शेयरिंग के लिए विभिन्न कंपनियों के ऐप्स में साझा उपयोगकर्ता पहचान बनाती हैं, तो ऐप ट्रैकिंग ट्रांसपेरेंसी (ATT) प्राधिकरण की आवश्यकता होती है। हालाँकि, ATT सहमति प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग को अनुमति योग्य नहीं बनाती है।
• अनुपालन वृद्धि और सत्यापन आवश्यकता: यदि कोई विशिष्ट SDK संस्करण या कॉन्फ़िगरेशन प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग पर निर्भर करता है, तो न तो सामान्य आंतरिक डेटा ऑडिट करना और न ही ATT संकेत के माध्यम से उपयोगकर्ता की सहमति प्राप्त करना उस तंत्र को Apple के दिशानिर्देशों के अनुरूप बनाता है। यदि विक्रेता यह प्रदर्शित नहीं कर सकता है कि iOS मिलान तंत्र प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग से बचता है, तो डेवलपर्स को OWASP मोबाइल एप्लिकेशन सुरक्षा शासन प्रथाओं का पालन करते हुए, किसी संगत विकल्प के स्वतंत्र रूप से सत्यापित होने तक iOS पर उस एट्रिब्यूशन तंत्र को तैनात नहीं करना चाहिए।
• नेटवर्क टाइमिंग और अनएट्रिब्यूटेड फ़ॉलबैक: हालांकि iOS सामान्य इंटरनेट एक्सेस के लिए सामान्य उपयोगकर्ता-अनुमत अनुमति को उजागर नहीं करता है (डेवलपर्स को सामान्य इंटरनेट पहुंच को Apple की स्थानीय नेटवर्क गोपनीयता अनुमति से अलग करना चाहिए, जो स्थानीय-नेटवर्क डिवाइस खोज पर लागू होता है), SDK आरंभीकरण और पैरामीटर पुनर्प्राप्ति अभी भी नेटवर्क उपलब्धता और स्टार्टअप समय पर निर्भर करती है। चूंकि सभी नेटवर्क स्थितियों या विलंबित पहले लॉन्च पर डिफर्ड मिलान की गारंटी नहीं है, इसलिए जब लौटाए गए पैरामीटर खाली हों तो अनुप्रयोगों को हमेशा सुंदर फ़ॉलबैक प्रवाह लागू करना चाहिए।

मोबाइल एट्रिब्यूशन SDK संपूर्ण एप्लिकेशन लाइफ़साइकिल में कैसे काम करता है

चरण 1: Gradle और CocoaPods के माध्यम से निर्भरता प्रबंधन और बिल्ड-टाइम लिंकिंग

एक SDK का लाइफ़साइकिल संकलन के समय शुरू होता है जब डेवलपर Gradle, CocoaPods, या मैन्युअल आर्काइव आयात के माध्यम से लाइब्रेरी निर्भरता की घोषणा करता है। बिल्ड संकलन के दौरान, पैकेज मैनेजर लाइब्रेरी कलाकृति को हल करता है और इसके बाइनरी प्रतीकों को एप्लिकेशन पैकेज में जोड़ता है। कुछ मोबाइल SDK को रिलीज़ बिल्ड में विशिष्ट कोड-सिकुड़न संगतता विचारों की आवश्यकता होती है, और iOS SDK एकीकरण को प्लेटफ़ॉर्म-विशिष्ट गोपनीयता मैनिफेस्ट घोषणाओं और संगत बिल्ड कॉन्फ़िगरेशन की भी आवश्यकता हो सकती है।

चरण 2: एप्लिकेशन स्टार्टअप पर मुख्य-थ्रेड आरंभीकरण

जब कोई उपयोगकर्ता ऐप लॉन्च करता है, तो मोबाइल OS एप्लिकेशन प्रक्रिया बनाता है और एप्लिकेशन लाइफ़साइकिल पर Google एंड्रॉइड डेवलपर्स गाइड में विस्तृत एंड्रॉइड पर प्राथमिक एंट्री-पॉइंट लाइफ़साइकिल हुक—Application.onCreate(), और UIApplicationDelegate पर Apple डेवलपर दस्तावेज़ में विस्तृत iOS पर application(_:didFinishLaunchingWithOptions:) को आह्वान करता है। एक अच्छी तरह से डिज़ाइन किए गए मोबाइल SDK को एप्लिकेशन स्टार्टअप के दौरान काम को कम करना चाहिए और नेटवर्क संचालन को अतुल्यकालिक निष्पादन में स्थानांतरित करना चाहिए। डेवलपर्स को वास्तविक आरंभीकरण व्यवहार को सत्यापित करना चाहिए और अपने लक्षित बिल्ड में कोल्ड-स्टार्ट प्रदर्शन को मापना चाहिए।

चरण 3: यूनिवर्सल लिंक और इंटेंट फ़िल्टर के माध्यम से नेटिव डीप लिंक को इंटरसेप्ट करना

जब ऐप पहले से इंस्टॉल होता है और कोई उपयोगकर्ता H5 लिंक पर टैप करता है, तो OS एप्लिकेशन को जगाता है और प्लेटफ़ॉर्म-विशिष्ट एंट्री पॉइंट के माध्यम से SDK को रूटिंग संदर्भ वितरित करता है:

• एंड्रॉइड कस्टम स्कीमें बनाम सत्यापित ऐप लिंक: कस्टम URL स्कीमें (scheme://) एक बुनियादी BROWSABLE <intent-filter> के माध्यम से रूट होती हैं। सत्यापित एंड्रॉइड ऐप लिंक का समर्थन करने के लिए एक <intent-filter android:autoVerify="true"> की आवश्यकता होती है जो लक्ष्य android:host के साथ http और https दोनों स्कीमों की घोषणा करता है, जो ऐप के पैकेज नाम और SHA-256 हस्ताक्षर प्रमाण पत्र फ़िंगरप्रिंट वाली /.well-known/assetlinks.json डिजिटल एसेट लिंक फ़ाइल द्वारा समर्थित है।
• iOS AppDelegate और UISceneDelegate रूटिंग: यूनिवर्सल लिंक पारंपरिक लाइफ़साइकिल ऐप्स में AppDelegate को NSUserActivity वितरित करते हैं, या—UISceneDelegate के माध्यम से दृश्य-आधारित लाइफ़साइकिल अपनाने वाले iOS 13+ ऐप्स के लिए—कोल्ड लॉन्च पर scene(_:willConnectTo:options:) और वार्म रेज़्यूमे पर scene(_:continue:) को वितरित करते हैं।

चरण 4: अतुल्यकालिक पैरामीटर पुनर्स्थापना और इवेंट टेलीमेट्री कतारबद्ध करना

पहले लॉन्च पर—या जब व्यावसायिक रूपांतरण मील के पत्थर होते हैं—होस्ट एप्लिकेशन कैश किए गए इंस्टॉलेशन पैरामीटर (data और channelCode) को पुनर्प्राप्त करने और डाउनस्ट्रीम रूपांतरण घटनाओं (जैसे खाता पंजीकरण या कस्टम प्रभाव बिंदु) की रिपोर्ट करने के लिए SDK के अतुल्यकालिक तरीकों को आह्वान करता है।

एंड्रॉइड और iOS पर नेटिव SDK लाइफ़साइकिल हुक लागू करना

एप्लिकेशन आइडेंटिफ़ायर को कॉन्फ़िगर करना और SDK रिलीज़ को सत्यापित करना

नीचे दिए गए सचित्र एकीकरण पैटर्न यह प्रदर्शित करने के लिए OpoInstall के सार्वजनिक एकीकरण दस्तावेज़ का पालन करते हैं कि नेटिव एंड्रॉइड और iOS प्रोजेक्ट ऊपर वर्णित लाइफ़साइकिल हुक को कैसे तार-जोड़ते हैं। चूंकि डाउनलोड केंद्र अद्यतन SDK आर्काइव वितरित करता है (वर्तमान में v2.1.0, 2026-09-20 को जारी किया गया) जबकि दस्तावेज़ उदाहरण पहले के छोटे निर्देशांकों का संदर्भ दे सकते हैं, इंजीनियरिंग टीमों को लक्षित v2.1.0 SDK पैकेज डाउनलोड करना होगा, बंडल किए गए लाइब्रेरी हेडर के खिलाफ सभी आयात पथों और मेथड सिग्नचर को सत्यापित करना होगा, और उत्पादन तैनाती से पहले एंड्रॉइड स्टूडियो और एक्सकोड में एक स्वच्छ बिल्ड सत्यापन चलाना होगा। रिलीज़-विशिष्ट एकीकरण निर्देशों के लिए OpoInstall तकनीकी दस्तावेज़ देखें।

एंड्रॉइड SDK आरंभीकरण और पैरामीटर पुनर्प्राप्ति पैटर्न

AndroidManifest.xml में, नेटवर्क अनुमतियों, टेनेंट AppKey, और कस्टम URL स्कीम वेकअप और सत्यापित एंड्रॉइड ऐप लिंक के लिए अलग <intent-filter> ब्लॉक घोषित करें (एंड्रॉइड ऐप लिंक सत्यापन आवश्यकताओं के अनुसार http और https दोनों स्कीमों की घोषणा करना, और links.example.com को अपने सत्यापित डोमेन से बदलना):

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">

    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

    <application
        android:name=".CustomApplication"
        android:allowBackup="true">

        <meta-data
            android:name="com.opoinstall.APP_KEY"
            android:value="OPOINSTALL_APPKEY"/>

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTask">

            <!-- 1. कस्टम URL स्कीम वेकअप फ़िल्टर -->
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="OPOINSTALL_SCHEME"/>
            </intent-filter>

            <!-- 2. सत्यापित एंड्रॉइड ऐप लिंक फ़िल्टर (SHA-256 प्रमाण पत्र फ़िंगरप्रिंट के साथ /.well-known/assetlinks.json की आवश्यकता है) -->
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="http"/>
                <data android:scheme="https"/>
                <data android:host="links.example.com"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

// File: app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;

import android.app.Application;
import com.opoinstall.api.OpoInstall;

public class CustomApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        OpoInstall.initialize(this);
    }
}

// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
package com.example.app;

import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;
import com.opoinstall.api.OpoInstall;
import com.opoinstall.api.OpoData;
import com.opoinstall.api.OpoError;
import com.opoinstall.api.ResultCallBack;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "OpoInstallSDK";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        OpoInstall.getInstance().start(this);

        // कस्टम स्कीम या सत्यापित ऐप लिंक के माध्यम से लॉन्च होने पर वेकअप इंटेंट को संसाधित करें
        getWakeUpData(getIntent());

        // ऑनबोर्डिंग लॉजिक द्वारा आवश्यक होने पर डिफर्ड इंस्टॉलेशन पैरामीटर पुनर्प्राप्त करें
        OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "getInstallParam onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.e(TAG, "getInstallParam onError : " + opoError);
            }
        });
    }

    @Override
    protected void onNewIntent(Intent intent) {
        super.onNewIntent(intent);
        getWakeUpData(intent);
    }

    private void getWakeUpData(Intent intent) {
        OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "handleDeepLink onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.d(TAG, "handleDeepLink onError : " + opoError);
            }
        });
    }
}

iOS SDK डेलिगेट पंजीकरण और SceneDelegate वेकअप पैटर्न

iOS पर, अपने Objective-C ब्रिजिंग हेडर में #import "OpoInstallSDK.h" को उजागर करें, Info.plist में com.opoinstall.APP_KEY को कॉन्फ़िगर करें, और OpoInstallDelegate को लागू करें। उन अनुप्रयोगों के लिए AppDelegate URL-हैंडलिंग विधियों का उपयोग करें जो दृश्य-आधारित लाइफ़साइकिल प्रबंधन को नहीं अपनाते हैं; दृश्य-आधारित अनुप्रयोगों के लिए, संबंधित SceneDelegate विधियों के माध्यम से कोल्ड-स्टार्ट और वार्म-रेज़्यूमे यूनिवर्सल लिंक और URL स्कीम को संसाधित करें:

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    // उन ऐप्स के लिए जो UISceneDelegate लाइफ़साइकिल प्रबंधन को नहीं अपनाते हैं:
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        print("Wakeup data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Install data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// iOS 13+ ऐप्स के लिए जो UISceneDelegate लाइफ़साइकिल प्रबंधन को अपनाते हैं:
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        for userActivity in connectionOptions.userActivities {
            OpoInstallSDK.continue(userActivity)
        }
        for urlContext in connectionOptions.urlContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        OpoInstallSDK.continue(userActivity)
    }

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        for urlContext in URLContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }
}

इंजीनियरिंग टीमों को तृतीय-पक्ष मोबाइल SDK को कब एकीकृत करना चाहिए

विशिष्ट मोबाइल SDK को एकीकृत करने के लिए उपयुक्त परिदृश्य

एक समर्पित मोबाइल एट्रिब्यूशन और डीप-लिंकिंग SDK को एकीकृत करना निम्नलिखित स्थितियों में उचित है:

• कोड-मुक्त रेफ़रल और ऑनबोर्डिंग प्रवाह: रेफ़रल प्रोग्राम या मल्टीप्लेयर रूम आमंत्रण चलाने वाले एप्लिकेशन जहाँ स्टोर इंस्टॉलेशन के बाद मैन्युअल कोड प्रविष्टि के बिना पैरामीटर (?ref=userA या room_id=402) को पुनर्स्थापित किया जाना चाहिए।
• बहु-चैनल H5 और QR कोड कैंपेन: सोशल नेटवर्क, ऑफ़लाइन QR कोड, और एंड्रॉइड चैनल पैकेजों में लिंक वितरित करने वाली मार्केटिंग टीमें जिन्हें विज़िट, क्लिक, इंस्टॉलेशन और पंजीकरण के एकीकृत ट्रैकिंग की आवश्यकता होती है।
• वन-क्लिक वेब-टू-ऐप लॉन्चिंग: ऐसे उत्पाद जो मौजूदा ऐप उपयोगकर्ताओं को मोबाइल ब्राउज़र से यूनिवर्सल लिंक और ऐप लिंक के माध्यम से विशिष्ट इन-ऐप व्यू में सीधे रूट करते हैं और साथ ही अनइंस्टॉल किए गए उपयोगकर्ताओं को उचित ऐप स्टोर पर मार्गदर्शन करते हैं।

वे परिदृश्य जहाँ सीधा REST API पर्याप्त है

इसके विपरीत, जब कार्यप्रवाह नेटिव मोबाइल सैंडबॉक्स को पार नहीं करता है तो क्लाइंट-साइड एट्रिब्यूशन SDK अनावश्यक होता है:

• प्रमाणित बैकएंड लेनदेन: जब पहले से प्रमाणित उपयोगकर्ता सदस्यता का नवीनीकरण करता है या बैकएंड बिलिंग वेबहुक को ट्रिगर करता है, तो सीधे सर्वर-से-सर्वर (S2S) REST API के माध्यम से उस रूपांतरण को लॉग करने से क्लाइंट निर्भरता अपडेट बच जाते हैं।
• केवल-ब्राउज़र वेब एप्लिकेशन: प्रोग्रेसिव वेब ऐप्स (PWAs) और मोबाइल वेबसाइटें जो ऐप स्टोर या गूगल प्ले के माध्यम से नेटिव बाइनरी वितरित नहीं करती हैं, वे मानक प्रथम-पक्ष वेब कुकीज़ और URL क्वेरी पैरामीटर का उपयोग करके रेफ़रल को ट्रैक कर सकती हैं।

मोबाइल SDK के बारे में आम इंजीनियरिंग भ्रांतियाँ

• भ्रंति 1: मोबाइल SDK को एकीकृत करने से कोल्ड ऐप स्टार्टअप स्वचालित रूप से अवरुद्ध हो जाता है: एक अच्छी तरह से डिज़ाइन किया गया मोबाइल SDK Application.onCreate() या didFinishLaunchingWithOptions: के दौरान काम को कम करता है और नेटवर्क संचालन को अतुल्यकालिक निष्पादन में स्थानांतरित करता है, हालांकि डेवलपर्स को हमेशा अपने लक्षित बिल्ड में कोल्ड-स्टार्ट विलंबता का प्रोफ़ाइल बनाना चाहिए।
• भ्रंति 2: एंड्रॉइड चैनल पैकेज H5 लिंक चैनल ID को ओवरराइड करते हैं: जब कोई एंड्रॉइड ऐप निर्यातित चैनल APK और H5 चैनल लिंक दोनों का उपयोग करता है, तो OpoInstall SDK कस्टम पैरामीटर और चैनल ID को एक साथ पुनर्प्राप्त करने की अनुमति देता है; OpoInstall के उत्पाद दस्तावेज़ के अनुसार, यदि कोई इंस्टॉलेशन एक अलग channelCode वाले H5 चैनल लिंक से उत्पन्न होता है, तो सांख्यिकीय रिपोर्ट में चैनल पैकेज ID पर H5 चैनल लिंक ID को प्राथमिकता दी जाती है।

सारांश और आर्किटेक्चरल निर्णय ढांचा

यह समझना कि SDK क्या है और यह मोबाइल ऑपरेटिंग सिस्टम सैंडबॉक्स के भीतर कैसे काम करता है, इंजीनियरिंग टीमों को विश्वसनीय उपयोगकर्ता अधिग्रहण और डीप-लिंकिंग आर्किटेक्चर को डिज़ाइन करने की अनुमति देता है। जबकि स्टेटलेस वेब API रिमोट सर्वर संचार को संभालते हैं, जब किसी एप्लिकेशन को नेटिव लाइफ़साइकिल इवेंट में भाग लेने या प्लेटफ़ॉर्म-विशिष्ट इंस्टॉलेशन सिग्नल पुनर्प्राप्त करने की आवश्यकता होती है, तो एक नेटिव क्लाइंट-साइड एकीकरण की आवश्यकता होती है, और एक मोबाइल SDK इन क्षमताओं को एक पुन: प्रयोज्य एकीकरण परत में पैक करता है।

यह निर्णय लेते समय कि अपने एट्रिब्यूशन पाइपलाइन को कैसे संरचित किया जाए, इन इंजीनियरिंग दिशानिर्देशों को लागू करें:

• नेटिव मोबाइल SDK तैनात करें: जब उपयोगकर्ता यात्राएँ H5 लैंडिंग पेज, सोशल शेयर, या QR कोड से ऐप स्टोर या Google Play के माध्यम से संक्रमण करती हैं और स्वचालित पैरामीटर पुनर्स्थापना या वन-क्लिक यूनिवर्सल लिंक / ऐप लिंक रूटिंग की आवश्यकता होती है।

• सर्वर-से-सर्वर HTTP API का उपयोग करें: जब कुल चैनल आँकड़ों को आंतरिक डेटा वेयरहाउस में निर्यात करना हो, या जब क्लाइंट-साइड लॉन्च संदर्भ पर निर्भर न करने वाले बैकएंड इवेंट को रिकॉर्ड करना हो।

• बाइनरी संकलन और प्लेटफ़ॉर्म गोपनीयता अनुपालन को सत्यापित करें: हमेशा एक स्वच्छ प्रोजेक्ट में लक्षित SDK आर्काइव (जैसे v2.1.0) का संकलन-परीक्षण करें और उत्पादन रिलीज़ से पहले विक्रेता के साथ पुष्टि करें कि कोई भी iOS मिलान तंत्र प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग से बचाता है।

एट्रिब्यूशन बुनियादी ढांचे का मूल्यांकन करने वाली इंजीनियरिंग टीमें स्टेजिंग वातावरण में पैरामीटर पुनर्स्थापना और डीप-लिंक रूटिंग का परीक्षण करने के लिए OpoInstall डेवलपर कंसोल पर एक एप्लिकेशन कुंजी पंजीकृत कर सकती हैं।

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

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

• प्रौद्योगिकियाँ: एंड्रॉइड आर्काइव (.aar), iOS XCFramework, Google Play इंस्टॉल रेफ़रर, Apple यूनिवर्सल लिंक्स

• मानक: IETF RFC 9110 HTTP सिमेंटिक्स, IETF RFC 3986 URI जेनेरिक सिंटैक्स, OWASP मोबाइल एप्लिकेशन सुरक्षा प्रोजेक्ट

• प्लेटफ़ॉर्म और एकीकरण इंटरफेस: एंड्रॉइड Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

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

  • एप्लिकेशन लाइफ़साइकिल पर Google एंड्रॉइड डेवलपर्स गाइड

  • ऐप लिंक पर Google एंड्रॉइड डेवलपर्स गाइड

  • Google Play इंस्टॉल रेफ़रर API तकनीकी गाइड

  • UIApplicationDelegate पर Apple डेवलपर दस्तावेज़

  • UISceneDelegate पर Apple डेवलपर दस्तावेज़

  • यूनिवर्सल लिंक का समर्थन करने पर Apple डेवलपर दस्तावेज़

  • मल्टी-प्लेटफ़ॉर्म बाइनरी फ्रेमवर्क बंडल (XCFramework) बनाने पर Apple डेवलपर दस्तावेज़

  • Apple उपयोगकर्ता गोपनीयता और डेटा उपयोग दिशानिर्देश