شرحنا في المقال السابق كيف يصل العطل Crash من جوال المستخدم إليك، ولماذا يحتاج ال Stack Trace إلى ملف ال Mapping أو ال dSYM ليصبح مقروءاً، وكيف تقرأ نسبة المستخدمين دون أعطال Crash-free Users قبل أن توسع الإطلاق. والسؤال العملي بعد ذلك: أي أداة تضعها في تطبيقك؟ فأغلب الفرق تضيف Firebase Crashlytics لأنه مجاني ويأتي مع Firebase، ولكن هذا يعني أن تقارير الأعطال بكل ما فيها من معرفات وبيانات أجهزة تذهب إلى Google دون أن تختار مكانها، وأن تتبع الأعطال في تطبيق الجوال منفصل عن تتبع الأخطاء في السيرفر.
وفي هذا المقال نقارن الخيارات الثلاثة: الخدمات المجانية والتجارية المستضافة، والأدوات مفتوحة المصدر التي تستضيفها بنفسك، والمكتبات التي تلتقط العطل وتترك لك بناء ما بعده. والمقالات التالية تكمل الصورة، فالأول يشرح المفاهيم التي نبني عليها هنا، والثاني يشرح GlitchTip الذي نعود إليه في هذا المقال، والثالث مختبر عملي لتطبيق Android يرسل أعطاله إلى سيرفرك:
دليلتقارير الأعطال Crash Reporting في تطبيقات الجوالكيف يصلك عطل حدث في جوال مستخدم لا تعرفه، وكيف تقرأ ال Stack Trace المشفر، ومتى توقف إصداراً جديداً قبل أن يصل إلى الجميع.
دليلتقارير الأعطال Crash Reports لتطبيق Android مع GlitchTipتطبيق Android يتعطل عمداً على المحاكي ويرسل أعطاله إلى GlitchTip على سيرفرك، وما الذي يعمل فعلاً عند رفع ملف ال Mapping وما الذي لا يعمل.وسوف نتناول في هذا المقال:
- ما الذي تحتاجه فعلاً من أداة تقارير أعطال الجوال، وما الذي يعطيك إياه المتجر مجاناً دون أي SDK.
- Firebase Crashlytics: ما الذي يرسله إلى Google، وأين تحفظ البيانات، وكيف تؤجل الجمع حتى يوافق المستخدم.
- الخدمات التجارية Sentry وBugSnag وLuciq (Instabug سابقاً) وEmbrace وDatadog، بأسعارها ومناطق بياناتها كما ظهرت في 23 أكتوبر 2026.
- البدائل التي تستضيفها بنفسك: GlitchTip وCountly وACRA مع Acrarium، ومكتبات iOS مثل PLCrashReporter وKSCrash، مع تجربة Acrarium في Docker.
- جدول مقارنة، ومن يختار ماذا.
ما الذي تحتاجه من أداة تقارير الأعطال Crash Reporting؟
كل الأدوات في هذا المقال تلتقط ال Crash في Java وKotlin وSwift، ولذلك لا تقارن بها، وإنما بالأشياء التي تختلف فيها فعلاً، وفيما يلي المعايير التي نستخدمها في الجدول آخر المقال:
- المنصات SDK Support: هل لها SDK رسمي لكل ما تستخدمه، أي Android وiOS وFlutter وReact Native، أم أن بعضها مكتبة من طرف ثالث.
- أعطال الكود الأصلي Native/NDK: هل تلتقط إشارات C/C++ أم أعطال Java فقط، وتذكر أن مكتبات كثيرة في تطبيقك فيها كود أصلي دون أن تعرف.
- ما بعد ال Crash: ال ANR في Android، وتعليق التطبيق App Hang وإنهاء ال Watchdog ونفاد الذاكرة Out of Memory في iOS.
- استعادة الأسماء Symbolication: هل تقرأ ملف ال Mapping وال dSYM ورموز NDK، وهل ترفعها تلقائياً من البناء بإضافة Gradle أو سكربت Xcode.
- صحة الإصدار Release Health: هل تحسب Crash-free Users وCrash-free Sessions لكل إصدار، وهذا هو المقياس الذي تقرر به إيقاف الإطلاق التدريجي Staged Rollout.
- مكان البيانات Data Residency: أين تحفظ التقارير، وهل تستطيع اختيار المنطقة، وهل تستطيع استضافة الأداة داخل المملكة.
- نموذج السعر Pricing Model: بعدد الأحداث، أم الجلسات، أم المستخدمين النشطين، أم مجاني، وما الذي يحدث عند تجاوز الحد.
ما يعطيك إياه المتجر دون أي SDK
قبل أي أداة تذكر أن Google وApple تجمعان الأعطال من أجهزة المستخدمين الذين وافقوا على مشاركة بيانات التشخيص، فتجد في Android vitals داخل Play Console نسبة الأعطال ونسبة ال ANR التي يحاسبك بها المتجر، وحدودها 1.09% و0.47%، وتجد في Crashes Organizer في Xcode تقارير الأعطال من المستخدمين ومن مختبري TestFlight. وهذان مجانيان وليس فيهما أي كود في تطبيقك، ولكنهما لا يعطيانك ال Breadcrumbs ولا الأخطاء غير القاتلة Non-fatal ولا التنبيه الفوري، ولا يجمعان Android وiOS في لوحة واحدة، ولذلك فهما المرجع وليسا الأداة. وقد شرحنا ذلك بالتفصيل في المقال السابق.
Firebase Crashlytics المجاني الذي تختاره أغلب الفرق
Firebase Crashlytics جزء من Firebase، وهو مجاني بالكامل في الخطتين Spark وBlaze دون حد للأحداث بحسب صفحة أسعار Firebase، ويدعم رسمياً Apple وAndroid وAndroid NDK وFlutter وUnity، وأما React Native فعبر مكتبة react-native-firebase التي تبنيها وتصونها شركة Invertase وليست Google. وفي Android يلتقط Crashlytics الأعطال والأخطاء غير القاتلة وال ANR على الأجهزة من Android 11 وما بعده، ويرفع ملف ال Mapping تلقائياً بإضافة Gradle، وفي iOS يرفع ملفات dSYM بسكربت في مرحلة البناء، وأعطال NDK تحتاج إلى تفعيل nativeSymbolUploadEnabled لأنه غير مفعل افتراضياً، كما في صفحة NDK.
وما الذي يذهب إلى Google؟ بحسب صفحة الخصوصية والأمان في Firebase يرسل Crashlytics معرف تثبيت خاصاً به Crashlytics Installation UUID ومعرف التثبيت في Firebase، وال Stack Traces، وبيانات Minidump بصيغة Breakpad لأعطال NDK، ومعلومات الجهاز مثل الطراز والمعمارية والذاكرة والمساحة، ووقت العطل ورقم الإصدار، ويحتفظ بال Stack Traces والمعرفات 90 يوماً ثم يبدأ حذفها. وأما المكان فالصفحة نفسها تصنف Crashlytics ضمن الخدمات التي تعمل على بنية Google العالمية، وتقول إن Firebase قد يعالج البيانات ويحفظها في أي مكان لدى Google أو وكلائها منشآت فيه، ولا يوجد اختيار للمنطقة إلا لمجموعة البيانات Dataset عند التصدير إلى BigQuery.
وإذا كان تطبيقك يحتاج إلى موافقة المستخدم قبل جمع التقارير، فعطل الجمع التلقائي في ملف AndroidManifest.xml كما في صفحة تخصيص التقارير:
<application>
<meta-data
android:name="firebase_crashlytics_collection_enabled"
android:value="false" />
</application>ثم فعله في الكود بعد أن يوافق المستخدم:
Firebase.crashlytics.setCrashlyticsCollectionEnabled(true)لاحظ أن هذه القيمة تبقى بين مرات التشغيل، وأن التقارير التي تحدث قبل الموافقة تحفظ على الجهاز ولا ترسل، وفي iOS يقابلها المفتاح FirebaseCrashlyticsCollectionEnabled في Info.plist. ولاحظ أيضاً حدود Crashlytics في الصفحة نفسها: 64 مفتاحاً مخصصاً Custom Keys لكل تقرير، و64 KB لل Logs، وآخر ثمانية استثناءات غير قاتلة في الجلسة فقط ترسل مع التقرير التالي.
نقاط القوة:
- مجاني دون حد للأحداث، وهذا ما لا تقدمه أي خدمة أخرى في هذا المقال.
- يرفع ملفات الرموز تلقائياً، ويلتقط ال ANR وأعطال NDK، ويرسل تنبيهاً عند المشكلات الجديدة والعائدة Regressed والمتسارعة Velocity Alerts.
- التصدير إلى BigQuery لمن يريد تحليل الأعطال مع بيانات أخرى، ويحتاج إلى خطة Blaze للتصدير الكامل.
نقاط الضعف:
- لا يمكنك اختيار مكان البيانات، ولا استضافته بنفسك.
- لا يغطي السيرفر ولا الويب، فأخطاء ال API التي سببت العطل في مكان آخر.
- React Native ليس مدعوماً رسمياً من Google، والحدود على المفاتيح والأخطاء غير القاتلة أضيق من الخدمات المدفوعة.
الخدمات التجارية المستضافة Hosted: Sentry وما يشبهها
الخدمات التالية تقدم ما يقدمه Crashlytics وأكثر، مثل تتبع الأداء وتسجيل الجلسات Session Replay وربط العطل بطلب السيرفر الذي سببه، ولكنها تحاسبك على الأحداث أو الجلسات أو المستخدمين، والأسعار التالية من صفحاتها الرسمية كما ظهرت في 23 أكتوبر 2026، وهي أسعار قوائم بالدولار قبل الضرائب.
Sentry
Sentry هو الأوسع في هذه القائمة، وله SDK رسمي ل Android وApple وFlutter وReact Native، وال SDK في Android يحتوي على جزء NDK مبني على sentry-native، ويكشف ال ANR عندما يتوقف ال Main Thread أكثر من 5 ثوان، ويقرأ ApplicationExitInfo في Android 11 وما بعده كما في صفحة ال ANR، وفي iOS يكشف تعليق التطبيق App Hang بعد ثانيتين افتراضياً، ويستنتج إنهاء ال Watchdog في التشغيل التالي ولا يحسبه Crash، كما في صفحة Watchdog Terminations. ويحسب صحة الإصدار Release Health بالجلسات والمستخدمين، وفيه Session Replay للجوال يخفي النصوص والصور ومدخلات المستخدم افتراضياً.
والأسعار في صفحة الأسعار: خطة Developer مجانية لمستخدم واحد فيها 5 آلاف خطأ شهرياً، وخطة Team بـ 26 دولاراً شهرياً بالدفع السنوي أو 29 شهرياً، فيها 50 ألف خطأ ومستخدمون بلا حد، وخطة Business بـ 80 دولاراً بالدفع السنوي. والبيانات في الولايات المتحدة (Iowa) أو الاتحاد الأوروبي (Frankfurt)، تختارها عند إنشاء المنظمة ولا تتغير بعدها، كما في صفحة مكان التخزين. وSentry نفسه يمكن استضافته، ولكن متطلباته كبيرة، وقد ناقشنا ذلك وترخيصه FSL في دليل تتبع الأخطاء.
نقاط القوة: يغطي الجوال والسيرفر والويب في أداة واحدة، فترى عطل التطبيق والخطأ في ال API الذي سببه، وال SDK الخاص به يعمل أيضاً مع GlitchTip الذي تستضيفه بنفسك، فتنتقل بينهما بتغيير ال DSN.
نقاط الضعف: الحصة المجانية 5 آلاف خطأ، وهي تنتهي بسرعة في تطبيق جوال له عشرات الآلاف من المستخدمين، ولا توجد منطقة في الشرق الأوسط.
BugSnag
BugSnag من SmartBear، وقد غيرت الشركة اسمه في 2025 إلى Insight Hub ثم عادت إلى BugSnag، والرابط القديم لصفحة أسعار Insight Hub يحول اليوم إلى صفحة BugSnag. وله SDK ل Android وiOS وReact Native وFlutter وUnity وغيرها كما في صفحة المنصات، وأشهر ما فيه مقياس الاستقرار Stability Score لكل إصدار، وهو نسبة الجلسات أو المستخدمين دون أخطاء مع هدف تحدده لكل مشروع، ولكن صفحة الاستقرار تقول إنه متاح في خطتي Preferred وEnterprise فقط. والخطة المجانية في صفحة الأسعار فيها 7,500 حدث شهرياً وحفظ 7 أيام، والخطط المدفوعة Select وPreferred بشرائح من 50 ألف إلى 3 ملايين حدث وحفظ 60 يوماً، وصفحة الأسعار لا تعرض أرقام الشرائح المدفوعة بشكل ثابت. والبيانات على Google Cloud في مراكز بيانات في الولايات المتحدة بحسب صفحة الأمان، وفي خطة Enterprise خيار التثبيت على سيرفراتك On-Premises.
نقاط القوة: مقياس الاستقرار لكل إصدار واضح للإدارة، ودعم واسع للمنصات، وخيار On-Premises لمن يحتاج البيانات عنده ويقبل عقد Enterprise.
نقاط الضعف: مقياس الاستقرار في الخطط العليا فقط، والبيانات في الولايات المتحدة، و SDK خاص به فالانتقال منه تعديل في الكود.
Luciq (Instabug سابقاً)
Instabug أصبح اسمه Luciq في 2025 كما تقول صفحة الأسئلة الشائعة، وهو موجه لفرق الجوال تحديداً، فيدعم iOS وAndroid وReact Native وFlutter، وتقاريره تفرق بين الأنواع كما في صفحة أنواع الأعطال: Fatal وNon-fatal وANR وOOM وApp Hang عندما يتوقف ال Main Thread أكثر من 3 ثوان، وأعطال NDK، وما يسميه Force Restart عندما يعيد المستخدم فتح التطبيق خلال 5 ثوان من إغلاقه، وفيه أيضاً تقارير الأخطاء التي يرسلها المستخدم بنفسه من داخل التطبيق. وأما السعر ففي صفحة الأسعار خطة واحدة تحسب بعدد المستخدمين النشطين يومياً DAU وعدد مقاعد الفريق، دون أرقام منشورة ودون خطة مجانية، وإنما بطلب عرض، وتذكر الصفحة استضافة عالمية مع خيار تثبيت المنطقة Regional Pinning دون أن تسمي المناطق.
نقاط القوة: تفصيل أنواع الأعطال الخاصة بالجوال، وبلاغات المستخدمين من داخل التطبيق مع لقطة الشاشة والسياق.
نقاط الضعف: لا يوجد سعر منشور ولا خطة مجانية، فهو للمؤسسات التي تقبل عقداً سنوياً.
Embrace
Embrace يبني مكتباته فوق OpenTelemetry، ومكتبة Android ومكتبة Apple مفتوحتا المصدر برخصة Apache-2.0، ومكتبة Apple تستخدم KSCrash الذي نشرحه في آخر المقال لالتقاط الأعطال. ويحاسب بالجلسات وليس بالأحداث، ففي صفحة الأسعار خطة مجانية حتى مليون جلسة في السنة لخمسة مستخدمين مع حفظ 3 أيام فقط للأحداث، وخطة Pro بـ 0.80 دولار لكل ألف جلسة بحد أدنى 80 دولاراً شهرياً وحفظ 14 يوماً. والبيانات في الولايات المتحدة أو الاتحاد الأوروبي بحسب صفحة المناطق.
نقاط القوة: مكتبات مفتوحة المصدر على OpenTelemetry، فتستطيع إرسال البيانات نفسها إلى منصة مراقبة أخرى، والسعر بالجلسات لا يرتفع فجأة مع عطل يتكرر في حلقة.
نقاط الضعف: مدة الحفظ قصيرة جداً في الخطط الأولى، 3 أيام في المجانية و14 في Pro.
Datadog RUM وError Tracking
إذا كانت شركتك تستخدم Datadog للسيرفرات، فله SDK للجوال ضمن RUM ل Android وiOS وFlutter وReact Native، يلتقط أعطال NDK وال ANR في Android، وتعليق التطبيق وإنهاء ال Watchdog في iOS، والأخيران غير مفعلين افتراضياً، كما في صفحة أعطال iOS. والسعر في قائمة الأسعار 0.15 دولار لكل ألف جلسة في RUM Measure بالعقد السنوي، و25 دولاراً شهرياً لأول 50 ألف خطأ في Error Tracking. ومواقع البيانات متعددة منها الولايات المتحدة وألمانيا واليابان وأستراليا والمملكة المتحدة بحسب صفحة المواقع. وقد حسبنا فاتورة Datadog الكاملة مقابل الاستضافة الذاتية في مقال تكلفة منصات المراقبة، ولذلك نكتفي هنا بأنه خيار منطقي لمن يدفع له أصلاً، وليس سبباً لتبدأ معه.
البدائل التي تستضيفها بنفسك Self-hosted
الخدمات السابقة كلها تحفظ البيانات في الولايات المتحدة أو أوروبا أو آسيا، ولا توجد لأي منها منطقة في الشرق الأوسط في صفحاتها الرسمية، فإذا كانت سياسة جهتك أو لائحة نقل البيانات الشخصية خارج المملكة تمنع خروج التقارير، فالخيار أن تستضيف الأداة على سيرفر داخل المملكة. والصورة التالية تبين الفرق بين النماذج الثلاثة:

GlitchTip
GlitchTip مفتوح المصدر برخصة MIT، ويستقبل الأحداث من SDK الخاص بـ Sentry نفسه، وصفحة ال SDK فيه تعرض إعداد Android وCocoa وFlutter وReact Native. ولملفات الرموز أداة سطر أوامر glitchtip-cli ترفع رموز الكود الأصلي dSYM وELF وخرائط المصدر Source Maps ورموز Dart في Flutter، وفي مستودع الكود وحدة لقراءة ملفات ProGuard/R8 Mapping يستخدمها عند إزالة التشفير.
ولكن هناك نقطة مهمة لتطبيقات الجوال: GlitchTip لا يدعم الجلسات Sessions، والأمثلة الرسمية في صفحات Flutter وCocoa وReact Native تعطل تتبع الجلسات صراحة مع تعليق «GlitchTip does not support sessions»، وهذا يعني أنه لا يحسب Crash-free Users ولا Crash-free Sessions، فتعرف عدد الأعطال وعدد المستخدمين المتأثرين بكل مشكلة، ولكن لا تعرف النسبة من كل مستخدمي الإصدار، وهي المقياس الذي تقرر به إيقاف الإطلاق. والحل العملي أن تأخذ هذه النسبة من Android vitals وXcode Organizer، وتستخدم GlitchTip للتحقيق في كل عطل. وقد شرحنا تثبيت GlitchTip وتجميع الأخطاء والإصدارات وإخفاء البيانات الشخصية في دليل تتبع الأخطاء.
وإذا أردته مستضافاً فخطته المجانية في صفحة الأسعار ألف حدث شهرياً، والمدفوعة من 15 دولاراً شهرياً لمئة ألف حدث، وهو أرخص بكثير من Sentry، ولكنه يحفظ البيانات عند GlitchTip وليس عندك.
نقاط القوة: خفيف، ورخصة MIT، ويستخدم SDK الخاص بـ Sentry فتنتقل بينهما دون تعديل الكود، ويجمع أخطاء الجوال والسيرفر في مكان واحد.
نقاط الضعف: لا يوجد Release Health ولا Crash-free، ولا Session Replay، وأداة رفع الرموز ما زالت بيتا Beta بحسب صفحتها.
Countly
Countly منصة تحليلات للتطبيقات Product Analytics، وتقارير الأعطال جزء منها، وله SDK ل Android وiOS وReact Native وFlutter وغيرها. ونسخته المفتوحة اسمها Countly Lite في مستودع countly-server، وفيها إضافة الأعطال Crashes، وآخر إصدار عند الكتابة 25.03.55 في 12 أكتوبر 2026. ولكن انتبه للترخيص: ملف الترخيص يسميه Countly Lite License، وهو AGPL-3.0 مع تعديل في القسم السابع يمنع إزالة شعار Countly وعلامته من الكود والواجهة، أي أنه ليس AGPL خالصاً. والأهم لتطبيقات الجوال أن استعادة الأسماء Symbolication، أي قراءة ملفات dSYM وProGuard، ليست في Lite، فبحسب صفحة Crash Symbolication هي إضافة متاحة في Countly Enterprise وإضافة مدفوعة في Flex، وFlex هي النسخة المستضافة وتبدأ من 175 دولاراً شهرياً في صفحة الأسعار، وأما Enterprise فبعقد سنوي.
نقاط القوة: تحليلات الاستخدام والأعطال في منصة واحدة تستضيفها بنفسك، فترى أن العطل يحدث بعد خطوة معينة في مسار المستخدم.
نقاط الضعف: بدون Symbolication في النسخة المفتوحة، أي أن أعطال تطبيق مبني بـ R8 أو تطبيق iOS تصلك مشفرة، والترخيص يشترط بقاء العلامة، والمنصة أثقل بكثير من أداة أعطال فقط لأنها تحتاج إلى MongoDB.
ACRA وAcrarium في Android
ACRA مكتبة Android مفتوحة المصدر برخصة Apache-2.0، وآخر إصدار لها 5.14.2 في أكتوبر 2026، تلتقط العطل وتكتب تقريراً بصيغة JSON فيه ال Stack Trace ومعلومات الجهاز والإصدار وما تختاره من الحقول، ثم ترسله في التشغيل التالي عبر HTTP إلى أي رابط تحدده، أو بالبريد في التطبيقات التي ليس لها صلاحية الإنترنت، كما في صفحة طرق الإرسال. وميزتها أنها لا تفرض سيرفراً، فتستطيع أن ترسل التقرير إلى ال API الخاص بك. وAcrarium هو ال Backend الرسمي لها، برخصة Apache-2.0، مبني على Spring Boot وMySQL، ويستقبل التقارير ويجمعها في أخطاء Bugs ويعرض إحصاءات بالإصدار والجهاز، ويقرأ ملف ال Mapping. ولكن لاحظ أن آخر إصدار مستقر له 1.8.1 في 2022، وأن الإصدار 2 ما زال بيتا، وآخره 2.0.0-beta13 في سبتمبر 2026.
ولأن صفحة Acrarium تذكر دعم ProGuard بلقطة شاشة فقط، شغلناه في Docker لنتحقق من أنه يعيد ال Stack Trace المشفر إلى أصله فعلاً. والملف التالي هو docker-compose.yml المبني على دليل الإعداد الرسمي، مع تثبيت رقم الإصدار بدلاً من الوسم next الذي يتغير، وكلمات المرور تولدها بالأمر openssl rand -hex 16:
services:
database:
image: mysql:8.3.0
environment:
MYSQL_ROOT_HOST: '%'
MYSQL_ROOT_PASSWORD: "change-me-root"
MYSQL_DATABASE: "acrarium"
MYSQL_USER: "acrarium"
MYSQL_PASSWORD: "change-me-db"
volumes:
- acrarium_data:/var/lib/mysql
command: ['mysqld', '--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci', '--max_allowed_packet=128M', '--log-bin-trust-function-creators']
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 5s
retries: 30
acrarium:
image: f43nd1r/acrarium:2.0.0-beta13
depends_on:
database:
condition: service_healthy
ports:
- "127.0.0.1:8080:8080"
restart: on-failure
environment:
SPRING_DATASOURCE_URL: jdbc:mysql://database:3306/acrarium?useSSL=false&allowPublicKeyRetrieval=true&useLegacyDatetimeCode=false&serverTimezone=UTC
SPRING_DATASOURCE_USERNAME: "acrarium"
SPRING_DATASOURCE_PASSWORD: "change-me-db"
volumes:
acrarium_data:في الإعداد أعلاه لاحظ التالي:
restart: on-failureمهم، ففي أول تشغيل فشل Acrarium بخطأCommunications link failureلأن MySQL كان ما زال يجهز قاعدة البيانات، ثم نجح بعد إعادة التشغيل التلقائية، وأخذ التشغيل الأول قرابة ثلاث دقائق.- عند فتح
http://127.0.0.1:8080تنشئ حساب المدير، وقد ظهرت لنا صفحة خطأ 500 بعد الضغط على Confirm مع أن الحساب أنشئ فعلاً، فإذا حدث ذلك فانتقل إلى/loginمباشرة. - عند إنشاء تطبيق جديد يعرض Acrarium إعداد ACRA مع اسم مستخدم وكلمة مرور للإرسال مرة واحدة فقط، فاحفظهما.
بعد ذلك أرسلنا تقريرين بصيغة JSON التي ترسلها ACRA، بالأمر curl بدلاً من جهاز Android، وال STACK_TRACE فيهما هو ال Stack Trace المشفر الحقيقي من تجربة R8 في المقال السابق، وهذا أحدهما بعد حذف حقلي التاريخ والعلامة التجارية:
{
"REPORT_ID": "03a7cc67-b891-4b7c-b902-b10cda3119ce",
"APP_VERSION_CODE": 1,
"APP_VERSION_NAME": "1.0.0",
"PACKAGE_NAME": "com.example.shop",
"ANDROID_VERSION": "14",
"PHONE_MODEL": "Pixel 8",
"STACK_TRACE": "java.lang.NullPointerException: Cannot invoke \"String.startsWith(String)\" because \"<parameter1>\" is null
at a.b.a(SourceFile:1)
at com.example.shop.Main.main(SourceFile:2)
",
"INSTALLATION_ID": "f55d80e9-b2bb-4d4e-a92a-30b86b468093",
"IS_SILENT": false,
"CUSTOM_DATA": { "screen": "checkout" }
}curl -u "$ACRA_LOGIN:$ACRA_PASSWORD" -H "Content-Type: application/json" --data-binary @report0.json http://127.0.0.1:8080/reportرد السيرفر بالرمز 200 لكل تقرير، وجمع Acrarium التقريرين في خطأ Bug واحد بعدد تثبيتين متأثرين Affected Installations، كما في الصورة التالية:

ثم رفعنا ملف mapping.txt للإصدار 1 من تبويب Admin، في قائمة Versions بزر التعديل، وعند فتح التقرير نفسه ظهر حقل De-obfuscated Stacktrace بالإطارات الأربعة الأصلية، مع أن التقرير وصل قبل رفع الملف، لأن Acrarium يطبق ال Mapping عند العرض:

نقاط القوة: خفيف ومفتوح بالكامل، والمكتبة لا ترسل شيئاً إلا إلى الرابط الذي تحدده، والتقرير JSON واضح تستطيع معالجته بنفسك.
نقاط الضعف: Android فقط، ولا يحسب Crash-free، وال Backend ما زال بيتا منذ سنوات.
مكتبات iOS مفتوحة المصدر PLCrashReporter وKSCrash
في iOS لا يوجد مقابل لمجموعة ACRA وAcrarium، ولكن توجد مكتبتان مفتوحتا المصدر تقوم عليهما أدوات كثيرة، وكل منهما تلتقط العطل وتكتب التقرير على القرص، وتترك لك إرساله ومعالجته:
- PLCrashReporter: مكتبة Microsoft، أصلها من Plausible Labs، برخصة من نوع MIT، تلتقط العطل داخل العملية نفسها In-process، وآخر إصدار 1.12.2 في نوفمبر 2025.
- KSCrash: برخصة MIT، تلتقط استثناءات Mach والإشارات واستثناءات C++ وObjective-C، وتسجل إنهاء النظام للتطبيق بسبب الذاكرة أو الحرارة أو المعالج، وتكشف تعليق ال Main Thread، وفيها طرق جاهزة لإرسال التقرير إلى رابط أو بالبريد، وآخر إصدار 2.6.0 في أغسطس 2026، وهي التي تستخدمها مكتبة Embrace في iOS.
وهذا الخيار مناسب لفريق يريد تحكماً كاملاً في التقرير ومكانه، ولكنه يعني أن عليك بناء الاستقبال والتجميع واستعادة الأسماء من ملفات dSYM، وهذا عمل كبير، ولذلك فالأنسب لأغلب الفرق أداة كاملة مثل GlitchTip تستخدم SDK الخاص بـ Sentry، وهي التي تتولى ذلك.
جدول المقارنة
الجدول التالي يجمع ما سبق، والأسعار من الصفحات الرسمية في 23 أكتوبر 2026:
| الأداة | النموذج | المجاني | أول سعر مدفوع | مكان البيانات | Android / iOS / Flutter / RN | Symbolication | Crash-free |
|---|---|---|---|---|---|---|---|
| Firebase Crashlytics | خدمة Google | بلا حد | لا يوجد | بنية Google العالمية دون اختيار | نعم / نعم / نعم / عبر مكتبة Invertase | نعم، تلقائياً | نعم |
| Sentry | مستضاف، أو ذاتي برخصة FSL | 5 آلاف خطأ | 26 دولاراً شهرياً | الولايات المتحدة أو ألمانيا | نعم / نعم / نعم / نعم | نعم | نعم |
| BugSnag | مستضاف، أو On-Premises في Enterprise | 7,500 حدث | بشرائح حسب الأحداث | الولايات المتحدة | نعم / نعم / نعم / نعم | نعم | في Preferred وEnterprise |
| Luciq | مستضاف | لا يوجد | بطلب عرض | عالمي مع خيار منطقة | نعم / نعم / نعم / نعم | نعم، بأداة CLI | لم نجده في التوثيق |
| Embrace | مستضاف، ومكتبات Apache-2.0 | مليون جلسة في السنة | 0.80 دولار لكل ألف جلسة، بحد أدنى 80 شهرياً | الولايات المتحدة أو الاتحاد الأوروبي | نعم / نعم / نعم / نعم | نعم | لم نجده في التوثيق |
| Datadog | مستضاف | لا يوجد | 0.15 دولار لكل ألف جلسة، و25 دولاراً لأول 50 ألف خطأ | عدة مواقع | نعم / نعم / نعم / نعم | نعم | نعم، Crash-free Sessions |
| GlitchTip | مفتوح MIT، أو مستضاف | بلا حد على سيرفرك | 15 دولاراً شهرياً مستضافاً | حيث تضع السيرفر | عبر Sentry SDK | dSYM وELF وR8 وFlutter | لا |
| Countly Lite | AGPL مع شرط العلامة | بلا حد على سيرفرك | Flex من 175 دولاراً شهرياً | حيث تضع السيرفر | نعم / نعم / نعم / نعم | في Enterprise وFlex فقط | لم نجده في التوثيق |
| ACRA + Acrarium | مفتوح Apache-2.0 | بلا حد على سيرفرك | لا يوجد | حيث تضع السيرفر | Android فقط | ملف Mapping | لا |
| PLCrashReporter / KSCrash | مكتبات MIT | مكتبة فقط | لا يوجد | حيث ترسلها أنت | iOS فقط | عليك بناؤها | لا |
من يختار ماذا؟
- تطبيق ناشئ أو شخصي، ولا قيود على مكان البيانات: Firebase Crashlytics، لأنه مجاني بلا حد ويرفع الرموز تلقائياً، ومعه Android vitals وXcode Organizer. ولكن صرح به في قسم أمان البيانات في المتجر، وأجل الجمع حتى الموافقة إذا كانت سياستك تتطلب ذلك.
- فريق لديه سيرفرات وويب ويريد أداة واحدة: Sentry المستضافة، وإذا كبر عدد الأحداث أو ظهر شرط مكان البيانات فانتقل إلى GlitchTip على سيرفرك بتغيير ال DSN فقط.
- جهة حكومية أو صحية أو مالية في المملكة: GlitchTip على سيرفر داخل المملكة، مع رفع ملفات الرموز من خط البناء، ومع أخذ نسبة Crash-free من Android vitals وXcode Organizer لأن GlitchTip لا يحسبها.
- تطبيق Android فقط وتريد أبسط شيء مفتوح: ACRA مع Acrarium، أو ACRA ترسل إلى ال API الخاص بك.
- فريق جوال كبير يريد تفصيل OOM وApp Hang وبلاغات المستخدمين: Luciq أو Embrace أو BugSnag، بحسب نموذج السعر الذي يناسبك، بالمستخدمين أو بالجلسات أو بالأحداث.
- تستخدم Countly للتحليلات أصلاً: أعطاله مفيدة لربط العطل بمسار المستخدم، ولكن احسب أن النسخة المفتوحة لن تقرأ ال Stack Trace المشفر.
وأياً كانت الأداة، فالأخطاء التي شرحناها في المقال السابق تبقى: ارفع ملف الرموز مع كل بناء، وهيئ المكتبة أول شيء عند التشغيل، ولا ترسل البريد أو رقم الجوال معرفاً للمستخدم، وأطلق كل إصدار تدريجياً.
الخلاصة
- Crashlytics مجاني بلا حد ويغطي Android وiOS وFlutter وNDK، ولكن البيانات على بنية Google العالمية دون اختيار للمكان، والحفظ 90 يوماً.
- Sentry الأشمل بين الخدمات المدفوعة، وحصته المجانية 5 آلاف خطأ، وSDK الخاص به يعمل مع GlitchTip الذي تستضيفه بنفسك.
- لا توجد لأي خدمة تجارية في المقارنة منطقة بيانات في الشرق الأوسط، فإذا كان مكان البيانات شرطاً فالحل استضافة ذاتية.
- GlitchTip هو الأنسب للاستضافة الذاتية مع SDK الخاص بـ Sentry، ولكنه لا يحسب Crash-free، فخذ النسبة من المتجر.
- Countly Lite لا يقرأ ملفات dSYM وProGuard، وAcrarium ل Android فقط وإصداره الثاني بيتا، وPLCrashReporter وKSCrash مكتبات تحتاج منك بناء ال Backend.
وفي المقال التالي بإذن الله نبني تطبيق Android يرسل أعطاله إلى سيرفرك، ونقرأ ال Stack Trace بعد رفع ملف ال Mapping.
سجل التحديثات
- أكتوبر 2026: كتابة المقارنة من الصفحات الرسمية بتاريخ 23 أكتوبر 2026، وتجربة Acrarium 2.0.0-beta13 في Docker.