الانتقال إلى المحتوى الرئيسي
SDK خفيف الوزن يعتمد على الخادم لتنفيذ التحقق من الهوية، ويتطلب الحد الأدنى من الإعدادات. أحدث إصدار: 4.13.2.

مستودع GitHub

اطّلع على الشيفرة المصدرية والإصدارات وسجل التغييرات الكامل على GitHub

حزمة SDK الأصلية: هذا هو الأسلوب الموصى به لتطبيقات iOS. توفر حزمة SDK الأصلية أفضل تجربة للمستخدم، ومعالجة محسّنة للكاميرا، ودعمًا كاملًا لتقنية NFC.


المتطلبات

توافق إصدارات iOS

تتطلب الموافقة البيومترية حزمة SDK الأصلية 4.10.0 أو أحدث. بالنسبة للأشخاص المشمولين بقوانين Illinois وTexas وColorado، يمكن لـ Didit أن تطلب الموافقة البيومترية الصريحة قبل أول التقاط للوجه. تعرض إصدارات iOS SDK 4.10.0 وما بعدها هذه الخطوة. ولا تستطيع الإصدارات السابقة عرض هذه الخطوة: تعمل جلساتها كما كانت من قبل، ويُبلغ القرار بأن الموافقة لم تُجمع (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). قم بالترقية إذا كنت تتحقق من هوية أشخاص في تلك الولايات.

التثبيت

منذ الإصدار 4.0.0 يُوزَّع SDK في عدة متغيرات قابلة للتثبيت، حتى لا يتحمل تطبيقك حجم الملف الثنائي إلا للميزات التي يستخدمها. اختر متغيراً واحداً بالضبط: subspec واحداً في CocoaPods ومنتج مكتبة واحداً في SwiftPM.
  • Core: الأخفّ حجماً، مع التقاط تلقائي للمستند وصورة السيلفي عبر أدوات الكشف الخفيفة الخاصة بـDidit. لا يتضمن OpenSSL.xcframework ولا بيئة تشغيل CoreNFC.
  • AutoDetection: مهجور منذ الإصدار 4.11.0 وهو مطابق لـCore؛ استخدم Core بدلاً منه.
  • NFC: Core مع قراءة شريحة جواز السفر أو الهوية الإلكترونية عبر NFC.
  • الكل: كل الميزات. وهذا هو الافتراضي عند تثبيت DiditSDK دون تسمية subspec أو منتج.
ما يضيفه كل متغير إلى حزمة تطبيقك (arm64 Mach-O، مقاساً على الإصدار 4.9.0): Core ~11.1 MB، NFC ~11.7 MB بالإضافة إلى ~4 MB من OpenSSL، AutoDetection ~16.0 MB، الكل ~16.6 MB بالإضافة إلى OpenSSL. تُنزَّل نماذج الكشف نفسها أثناء التشغيل وتُخزَّن مؤقتاً، لذلك لا تُحتسب أبداً ضمن حجم تنزيل تطبيقك. منذ الإصدار 4.11.0 يعمل الالتقاط التلقائي على أدوات الكشف الخفيفة الخاصة بـDidit في كل المتغيرات. لم يعد TensorFlow Lite جزءاً من SDK، وأصبح الإطار أصغر لأن ترجماته تُحمَّل من خارج الملف الثنائي. منذ الإصدار 4.6.0 لم تعد الأطر المُرسَلة تحتوي على واصفات Swift ABI (بيانات وصفية للبناء كان Xcode ينسخها إلى كل تطبيق دون أن يقرأها) ولا على فيديوهات تعليمية لا يستطيع المتغير تشغيلها. الترقية من 4.5.4 أو إصدار أقدم تقلّص حجم تطبيقك بنحو 7-8 MB وحدها، دون أي تغيير في الكود. يضغط App Store الملفات الثنائية عند التسليم، لذلك يكون حجم التنزيل عبر الهواء أقل. راجع تقرير حجم التطبيق في App Store Connect للحصول على الفرق الدقيق لكل جهاز.
يحتوي المتغيران NFC والكل على OpenSSL.xcframework (OpenSSL 3.3.3، ويُوزَّع باسم OpenSSL-Universal 3.3.3001 عبر NFCPassportReader)، وهو مطلوب للمصادقة على شريحة NFC ويحتاج إلى iOS 15.0+. الإصدارات حتى 4.0.6، بما فيها 4.0.6، كانت تحزم OpenSSL 1.1.1s؛ أما 4.0.7 وما بعده فتأتي مع OpenSSL 3.3.3 وله بيان خصوصية وتوقيع كود خاصان به، لذا ثبّت دائماً 4.0.7 أو أحدث. تجدر الإشارة إلى أن الترقية تُوحّد إصدارات OpenSSL لكنها لا تزيل تعارضات التضمين: إذا ضمّن اعتماد آخر في تطبيقك أيضاً OpenSSL.framework (بنفس اسم الملف ونفس معرّف الحزمة com.github.krzyzanowskim.OpenSSL)، فستتعارض النسختان عند خطوة التضمين بغض النظر عن الإصدار. احتفظ بنسخة واحدة فقط، مثلاً بتجاوز الحزمة الأخرى بواسطة هوية SPM لاستخدام OpenSSL.xcframework المنشور من Didit، حتى يكون الملف الثنائي في الحزمة هو الذي بُني عليه هذا SDK. أما متغيرا Core وAutoDetection فلا يربطان OpenSSL إطلاقاً.
تبقى import DiditSDK كما هي في كود تطبيقك بغض النظر عن المتغير الذي تثبّته.

Swift Package Manager (موصى به)

أضف الحزمة إلى مشروعك عبر Xcode:
  1. انتقل إلى File > Add Package Dependencies
  2. أدخل عنوان URL للمستودع:
  1. اختر الإصدار (أو Up to Next Major بدءاً من 4.13.2) ثم انقر Add Package
  2. عند ظهور سؤال اختيار المنتج، اختر منتج مكتبة واحداً بالضبط لمتغيرك (راجع الجدول أعلاه)
أو في ملف Package.swift الخاص بك:
ثم أضف منتجاً واحداً بالضبط من هذه المنتجات إلى الهدف (target) في مشروعك:
لا يفرض Swift Package Manager حد iOS 15 عليك. يعلن Package.swift عن platforms: [.iOS(.v13)] للحزمة كلها، لذا سيسمح لك Xcode بإضافة DiditSDK أو DiditSDKNFC إلى هدف يعمل بـiOS 13 أو 14 دون أي اعتراض، مع أن الاثنين يحزمان OpenSSL.xcframework ويقرآن الشرائح عبر NFCPassportReader، وهما يحتاجان إلى iOS 15.0+. اضبط هدف النشر لهدفك على 15.0 بنفسك عند استخدام منتج All أو NFC. أما CocoaPods فيفرض ذلك تلقائياً عبر deployment_target الخاص بالـsubspec.

CocoaPods

يُوزَّع DiditSDK كـpodspec ثنائي مستضاف في المستودع (وليس على CocoaPods Trunk العام)، لذا يجب أن تشير إلى رابط الـpodspec. اختر subspec واحداً بالضبط:
يدعم Core وAutoDetection iOS 13 كحد أدنى، أما NFC وAll فيحتاجان إلى iOS 15 بسبب NFCPassportReader. ثم شغّل:
بعد pod install، افتح ملف .xcworkspace المُنشأ (وليس .xcodeproj).
أخطاء rsync في Xcode 15+: إذا ظهرت أخطاء rsync من نوع Operation not permitted أثناء البناء، فاضبط Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) على No في المشروع لكل من Debug وRelease.

التثبيت اليدوي (XCFramework)

ينشر كل إصدار إطار XCFramework واحداً لكل متغير. نزّل ملفات zip لمتغيرك من صفحة GitHub Releases، ثم اسحب مجلدات .xcframework إلى Xcode واضبط Embed & Sign.

الأذونات

يتطلب SDK الأذونات التالية. أضفها إلى ملف Info.plist الخاص بتطبيقك:

أمثلة على إدخالات Info.plist

إعداد NFC

مطلوب فقط عند تثبيت نسخة NFC أو الكل. تخطَّ هذا القسم إذا ثبّتَّ نسخة Core أو AutoDetection. لتفعيل قراءة NFC لجوازات السفر وبطاقات الهوية المزودة بشرائح:
  1. أضف إمكانية NFC في Xcode:
    • اختر الهدف (Target) الخاص بك ← Signing & Capabilities ← + Capability ← Near Field Communication Tag Reading
  2. أضف معرّفات ISO7816 إلى Info.plist:
يتيح المعرّف D392F000260100000001 للـ SDK قراءة بطاقة My Number اليابانية عبر JPKI، فمن دونه لا يُبلغ iOS الـ SDK بوجود البطاقة. قراءة بطاقة My Number غير مفعّلة في بيئة الإنتاج بعد، ولا يغيّر المعرّف شيئاً بالنسبة إلى المستندات الأخرى، لذا يمكنك إضافته الآن.
  1. أضف الاستحقاقات (في ملف .entitlements الخاص بك):
قيد المحاكي (نسخ NFC والكل): تربط هذه النسخ مكتبة CoreNFC، ومنذ Xcode 12 لم يعد الملف libnfshared.dylib موجوداً في المحاكيات. راجع هذا الموضوع على Stack Overflow للاطلاع على حل بديل. هذا لا ينطبق على نسخة Core أو AutoDetection. اختبر ميزات NFC على الأجهزة الفعلية فقط.

مراجعة App Store (نسخ NFC والكل): إذا ثبّتَّ نسخة NFC أو الكل، فقد يطلب Apple فيديو توضيحياً أثناء المراجعة، لأن الشيفرة المرتبطة بـ NFC جزء من ملف الـ SDK الثنائي، حتى لو لم يستخدم سير العمل الخاص بك NFC. اطلب فيديو العرض التوضيحي لـ NFC لإرساله إلى Apple من support@didit.me. هذا لا ينطبق على نسخة Core أو AutoDetection.


البدء السريع

تكامل SwiftUI

تكامل UIKit


طرق التكامل

يدعم SDK طريقتين للتكامل: لا يتطلب خادماً خلفياً. يُنشئ SDK الجلسة مباشرة باستخدام معرّف سير العمل الخاص بك من Didit Console. تدعم طريقة UniLink (startVerification(workflowId:)) الحقل vendorData فقط، ولأي معامل آخر للجلسة استخدم الطريقة 2.
لكي يُرفق vendorData بالجلسة عبر UniLink، فعّل خيار بيانات البائع في Didit Console.

الطريقة 2: جلسة من الخادم الخلفي (موصى بها للإنتاج)

ينشئ خادمك الخلفي الجلسة عبر واجهة إنشاء جلسة التحقق (Create Verification Session API) (POST /v3/session/) مع دعم كامل للمعاملات (contact_details, expected_details, metadata, callback، وغيرها)، ثم يمرر session_token إلى SDK.
تمنحك هذه الطريقة تحكماً كاملاً في:
  • ربط الجلسات بمستخدميك (vendor_data)
  • تحديد بيانات الاتصال والبيانات المتوقعة للتحقق المتبادل
  • تعيين بيانات وصفية مخصصة
  • ضبط روابط الاستدعاء لكل جلسة تُرسل هذه البيانات (بيانات الاتصال، والبيانات المتوقعة، والبيانات الوصفية، ورابط الاستدعاء) إلى واجهة إنشاء جلسة التحقق.

الإعدادات

خصِّص سلوك SDK باستخدام DiditSdk.Configuration:

خيارات الإعداد

خيارات الكاميرا

تتطابق خيارات الكاميرا مع خيارات الكاميرا في Web SDK. كل عدسة هي .front أو .back. إذا لم يكن الجهاز يملك العدسة المطلوبة، يستخدم SDK أول كاميرا متاحة لديه. يُخفى مبدِّل الكاميرا أيضاً على الأجهزة التي تملك كاميرا واحدة فقط. اضبط خيار المبدِّل على false لتثبيت المستخدم على العدسة الافتراضية لتلك الخطوة.
المظهر والألوان: تُضبط الألوان والخلفيات وإعدادات شاشة المقدمة من خلال إعدادات العلامة البيضاء في Didit Console، وليس من خلال إعدادات SDK. هذا يضمن تناسق الهوية البصرية عبر جميع المنصات.
الخيارات showLanguageSelector وshowCloseButton وshowExitConfirmation وcloseOnComplete تطابق DiditSdkConfiguration في Web SDK. أما الخيارات الخاصة بالجوال languageLocale وfontFamily فموجودة لأن SDK للجوال يعرض واجهة التحقق الكاملة بشكل أصلي (على عكس Web SDK الذي يفوّض العرض إلى الواجهة المستضافة داخل iframe).

دعم اللغات

يدعم SDK 54 لغة. إذا لم تُحدَّد لغة، يستخدم SDK لغة الجهاز، مع الإنجليزية كبديل.
عرض جميع اللغات المدعومة ←

معلمات الجلسة المتقدمة

لاستخدام معلمات الجلسة المتقدمة (contact_details وexpected_details وmetadata وcallback)، استخدم طريقة Backend Session. يستدعي الخادم الخلفي لديك واجهة برمجة تطبيقات إنشاء جلسة التحقق بالمعلمات الكاملة، ثم يمرر session_token إلى SDK.

معالجة النتائج

يوفر التعداد VerificationResult نتيجة التحقق:

حالات النتيجة

خصائص SessionData

أنواع الأخطاء

فقدان الاتصال

إذا فقد الجهاز اتصاله أثناء التحقق، يعرض SDK شاشة “لا يوجد اتصال بالإنترنت” بدلاً من ترك الخطوة قيد التحميل. يواصل SDK التحقق من الاتصال في الخلفية، ويغلق الشاشة تلقائياً بمجرد إمكانية الوصول إلى Didit مرة أخرى، فيكمل المستخدم من الخطوة التي كان عليها. تعرض الشاشة الزر حاول مرة أخرى و، عندما تكون قيمة showCloseButton هي true (القيمة الافتراضية)، الزر الخروج من التحقق. الخروج ينهي التحقق بالنتيجة .failed(error: .networkError, session:)، فيعرف تطبيقك أن المستخدم خرج بسبب الاتصال.

مثال كامل لمعالجة النتائج


إغلاق التحقق برمجياً

متاح في DiditSDK ابتداءً من الإصدار 3.6.0+.
يمكن للتطبيق المضيف إنهاء التحقق النشط برمجياً باستخدام DiditSdk.shared.dismiss(). وهذه هي الطريقة الموصى بها لإنهاء التحقق عندما يحتاج التطبيق المضيف إلى تولّي التحكم في الشاشة، على سبيل المثال عندما ينتقل التطبيق إلى الخلفية.
يمرّ dismiss() عبر مسار الإكمال المعتاد في SDK: يُغلق الواجهة المعروضة، ويُعيد ضبط الحالة الداخلية، ويستدعي المعالج .diditVerification مع .cancelled(session:) الذي يحمل sessionId الحالي إذا كانت جلسة قد أُنشئت. ولا يكون لاستدعائه أي أثر عندما لا يكون هناك تحقق نشط.

مثال: الإغلاق عند انتقال التطبيق إلى الخلفية

لا تُعيّن DiditSdk.shared.isPresented = false للإغلاق، فهذا العلَم يُفعِّل العرض عند حافته الصاعدة فقط، وتعيينه إلى false لا يُحدث أي أثر. وبالمثل، فإن استدعاء dismiss(animated:) من UIKit على أعلى متحكم عرض غير مدعوم، إذ يتجاوز مسار الإكمال في SDK، فلا يُستدعى المعالج .diditVerification أبداً.

مراقبة حالة SDK

يمكنك مراقبة حالة SDK لبناء واجهة تحميل مخصصة:

مثال شامل (من جلسة الخادم الخلفي إلى SDK لنظام iOS إلى النتيجة)

هذا النمط هو التكامل الجاهز للإنتاج. يُنشئ الخادم الخلفي الجلسة، ويستلم تطبيق iOS الخاص بك session_token، ويُشغّل SDK مسار التحقق.

1. الخادم الخلفي: إنشاء الجلسة

2. iOS: تبادل الرمز وبدء SDK

3. الخادم الخلفي: استلام القرار النهائي عبر webhook

نتيجة SDK مناسبة لتقديم ملاحظات إلى واجهة المستخدم، لكن النتيجة المعتمدة تصل عبر webhook. راجع دليل webhook للتحقق من HMAC.

مثال SwiftUI كامل


آخر تعديل في ٧ نوفمبر ٢٠٢٦