قائمة استلام تطبيق من شركة البرمجة: 40 بندًا من المستودع إلى كلمات المرور

تقترب نهاية المشروع أو تنوي تغيير المزود، ولا تعرف بالتحديد ما الذي يجب أن تستلمه. هذه قائمة من 40 بندًا في عشر مجموعات، لكل بند طريقة تتحقق بها أنك استلمته فعلًا، وترتيب ينتهي بمحضر قبل الدفعة الأخيرة.

المشاريع المتعثرة والاستلامقراءة 14 دقيقة4 أكتوبر 2026

اطلب مراجعة الاستلاماحجز اجتماعًا تقنيًا
الإجابة المختصرة

الاستلام الحقيقي ليس ملف كود مضغوطًا ولا رسالة فيها كلمات مرور. هو أن يستطيع فريقك، أو أي شركة تختارها، أن يبني التطبيق وينشره ويشغّله ويستعيد بياناته دون أن يحتاج إلى الشركة السابقة في شيء. لذلك تغطي قائمة استلام تطبيق من شركة برمجة عشر مجموعات: الكود والمستودع، والبيئات ومتغيراتها، وقاعدة البيانات والنسخ، والتوثيق وواجهات API، وملفات التصميم، وحسابات المتاجر والتوقيع، والاستضافة والنطاق وDNS والشهادات، والمفاتيح والأسرار، وحسابات الخدمات الخارجية، ولوحات الإدارة. ولكل بند اختبار عملي يثبت أنك استلمته فعلًا، لا أنك وُعدت به.

أغلب مشكلات الاستلام لا تظهر يوم التسليم. تظهر بعد شهرين: حين تريد رفع تحديث عاجل فتكتشف أن مفتاح التوقيع عند المطور، أو حين ينتهي النطاق لأنه مسجل بحساب شخصي، أو حين يتعطل الخادم فلا تجد نسخة احتياطية جُرّبت استعادتها يومًا. هذه القائمة مكتوبة لتُستخدم قبل الدفعة الأخيرة، أو قبل الانتقال إلى مزود جديد، أو عند استلام مشروع توقف في منتصفه. انسخها، وأرسلها إلى الشركة قبل موعد التسليم بوقت كافٍ، واطلب أن يُثبت كل بند أمامك.

كيف تستخدم القائمة: الترتيب والمسؤول ومتى تُوقّع

البنود الأربعون ليست متساوية. بعضها يمكن استكماله بعد التسليم بأسبوع دون ضرر، وبعضها إن فات لا يُسترد بسهولة، مثل مفتاح توقيع Android المفقود في تطبيق لا يستخدم توقيع Google Play، أو مفتاح إشعارات Apple الذي لا يُحمَّل إلا مرة واحدة. لذلك نفّذ الاستلام بترتيب ثابت، ولا تجعل التوقيع على المحضر خطوة تسبق الاختبار.

ترتيب الاستلام: من الجرد إلى الدفعة الأخيرة
  1. الجردقائمة بكل أصل ومكانه ومالكه الحاليالشركة المطورة
  2. نقل الملكيةالمستودع والمتاجر والاستضافة والنطاق والخدماتالطرفان
  3. اختبار الاستقلالبناء ونشر واستعادة نسخة دون مساعدة المطورفريقك أو جهة مستقلة
  4. التدوير والإغلاقتغيير الأسرار وإلغاء صلاحيات من غادرفريقك
  5. محضر الاستلامكل بند: مستلم، أو مستثنى بسبب مكتوبالطرفان
  6. الدفعة الأخيرةبعد المحضر لا قبلهمنشأتك
كيف تقرأه: الجرد تكتبه الشركة المطورة لأنها تعرف ما بنته، لكن نقل الملكية يحتاج الطرفين، واختبار الاستقلال يجب أن ينفذه غيرها: فريقك أو مطور تثق به أو جهة مراجعة مستقلة. المرحلة الثالثة هي المحورية، لأنها الوحيدة التي تكشف ما نُسي في الجرد. والمحضر بوابة لا تُفتح الدفعة الأخيرة قبلها.

بنود توقف الدفعة الأخيرة إن لم تكتمل: 1 و5 (المستودع والبناء من الصفر)، و11 و14 (صلاحية قاعدة البيانات وتجربة الاستعادة)، و21 إلى 24 (حسابات المتاجر والتطبيق وتوقيع Android)، و27 و28 (حساب الاستضافة والنطاق). البقية مهمة، لكن يمكن أن يُتفق على موعد لاستكمالها في المحضر نفسه.

الكود والمستودع والبناء: البنود 1–7

الكود المسلَّم على قرص أو رابط تنزيل لا يثبت شيئًا. ما يثبت الاستلام هو مستودع تملكه، فيه التاريخ كله، ويُبنى منه ما هو منشور فعلًا.

الكود والمستودع: البند وطريقة التحقق
البندكيف تتحقق منه
1. المستودع داخل حساب مؤسسي تملكه المنشأة (GitHub أو GitLab أو غيرهما)افتح إعدادات الحساب المؤسسي وتأكد أن دورك «مالك» لا «متعاون»، وأن حسابات الشركة المطورة بصلاحيات أدنى يمكنك إلغاؤها.
2. كل المستودعات، لا مستودع التطبيق وحدهقارن القائمة بمكونات النظام: تطبيق الجوال، والخادم، ولوحة التحكم، وأي خدمة مساعدة أو سكربت بنية. كل مكون يعمل في الإنتاج يجب أن يقابله مستودع.
3. التاريخ الكامل للتعديلات والفروعسجل التعديلات (Commits) يمتد إلى بداية المشروع، لا «رفعة واحدة» بتاريخ التسليم. التاريخ هو ما يشرح لماذا كُتب الكود هكذا.
4. وسم (Tag) لكل إصدار منشوررقم الإصدار في App Store وGoogle Play يقابله وسم في المستودع، والكود العامل على خادم الإنتاج يقابله تعديل محدد يمكن الإشارة إليه.
5. البناء من جهاز نظيف باتباع التعليمات المكتوبةأهم اختبار في القائمة: مطور لم يعمل في المشروع يبني نسخة iOS وAndroid والخادم من الصفر، باتباع ملف README وحده. كل سؤال يضطر إلى طرحه على المطور السابق بند ناقص في التوثيق.
6. إصدارات الأدوات والاعتماديات مثبتةملفات القفل (مثل pubspec.lock أو package-lock.json أو composer.lock) موجودة في المستودع، وإصدار Flutter أو Node أو PHP المستخدم مكتوب.
7. لا أسرار داخل الكود ولا في تاريخهفحص آلي للأسرار على التاريخ كله لا على النسخة الأخيرة فقط. أي مفتاح يظهر ولو في تعديل قديم يعامل كمكشوف، ويدخل في التدوير (البند 33).

إن كانت لديك شكوك في جودة ما تستلمه، لا في اكتماله فقط، فالبنود السبعة لا تكفي. مراجعة الكود وتدقيق المعمارية تفحص الجودة والأمن وقابلية الصيانة، وتعطيك تقريرًا مرتبًا بالخطورة قبل أن توقع.

البيئات وقاعدة البيانات والنسخ الاحتياطي: البنود 8–14

الكود بلا بيئاته مثل مفتاح بلا عنوان. التطبيق يعمل لأن خادمًا ما يحمل عشرات القيم: عنوان قاعدة البيانات، ومفاتيح الخدمات، وإعدادات البريد والتخزين. هذه القيم لا تكون في المستودع، ولهذا تضيع كثيرًا.

البيئات والبيانات: البند وطريقة التحقق
البندكيف تتحقق منه
8. قائمة البيئات وعناوينهاتطوير، واختبار (Staging)، وإنتاج: لكل بيئة عنوانها وخادمها وقاعدتها. إن لم توجد بيئة اختبار أصلًا فاكتب ذلك في المحضر، فهو معلومة مهمة لمن سيكمل.
9. متغيرات البيئة لكل بيئةملف قالب في المستودع بأسماء كل المتغيرات، وقيمها الفعلية تُسلَّم عبر خزنة كلمات مرور لا عبر البريد أو المحادثة. قارن عدد المتغيرات على الخادم بعددها في القالب.
10. خط البناء والنشر (CI/CD)الخط يعمل من حساب المنشأة لا من حساب المطور، وأسراره منقولة. اطلب من فريقك تشغيل نشر تجريبي إلى بيئة الاختبار دون مساعدة.
11. صلاحية مالك على قاعدة بيانات الإنتاجمستخدم إداري باسم المنشأة، لا مستخدم التطبيق المحدود فقط. جرّب الدخول بأداة إدارة قواعد البيانات، واطّلع على قائمة المستخدمين الموجودين عليها.
12. المخطط وملفات الترحيل (Migrations)تشغيل ملفات الترحيل على قاعدة فارغة ينتج المخطط نفسه الموجود في الإنتاج. الفروق تعني تعديلات يدوية لم تُوثق.
13. سياسة النسخ الاحتياطيمتى تؤخذ النسخ، وأين تُحفظ (في حساب المنشأة)، وكم تبقى، ومن يُنبَّه إن فشلت نسخة.
14. تجربة استعادة ناجحةاستعد آخر نسخة على بيئة منفصلة وافتح التطبيق عليها. النسخة التي لم تُجرَّب استعادتها افتراض، لا نسخة.

التوثيق وواجهات API وملفات التصميم: البنود 15–20

التوثيق هو ما يحدد كم ستدفع لأول مطور بعد الاستلام ليفهم النظام. لا تطلب «توثيقًا كاملًا» بعبارة عامة؛ اطلب هذه الوثائق بأسمائها.

التوثيق والتصميم: البند وطريقة التحقق
البندكيف تتحقق منه
15. وثيقة المعماريةمخطط يبين المكونات، وأين يعمل كل منها، وكيف تتواصل، وما الخدمات الخارجية المرتبطة بكل منها. صفحة أو صفحتان تكفيان إن كانتا صحيحتين.
16. توثيق واجهات APIملف مواصفات (مثل OpenAPI) أو مجموعة طلبات جاهزة، فيها طريقة المصادقة وأكواد الأخطاء. جرّب ثلاثة طلبات من التوثيق على بيئة الاختبار؛ إن لم تعمل كما هي مكتوبة فالتوثيق قديم.
17. دليل التشغيلخطوات النشر، والتراجع عن إصدار معيب، وإعادة تشغيل الخدمات، وتجديد الشهادات، وما يُفعل عند كل تنبيه. اختبره بسؤال: هل يستطيع شخص جديد تنفيذ التراجع منه وحده؟
18. المشكلات المعروفة والأعمال الناقصةقائمة مكتوبة بالأعطال المعروفة، والمزايا غير المكتملة، والحلول المؤقتة في الكود. غيابها لا يعني أنه لا توجد مشكلات، بل أن أحدًا لم يكتبها.
19. ملفات التصميم الأصليةالملف المصدري في أداة التصميم منقول إلى مساحة عمل تملكها المنشأة، لا رابط مشاهدة يمكن سحبه في أي وقت.
20. الأصول وتراخيصهاالأيقونات والشعار بصيغ مصدرية، والخطوط مع ما يثبت ترخيصها للاستخدام في التطبيق، ولقطات المتجر بمقاساتها.

بند واجهات API وحده يستحق تفصيلًا، لأن غيابه يجعل أي تطبيق جديد أو تكامل لاحق يبدأ بقراءة الكود سطرًا سطرًا. مقالة توثيق واجهات API قبل نهاية المشروع تفصّل ما تطلبه بالتحديد.

حسابات المتاجر والتوقيع: البنود 21–26

هنا تقع أثقل خسائر الاستلام، لأن بعض ما يضيع في المتاجر لا يُستعاد. الفكرة الأساسية: التطبيق يجب أن يكون في حساب مطور باسم منشأتك، ومفاتيح توقيعه في يدك.

المتاجر والتوقيع: البند وطريقة التحقق
البندكيف تتحقق منه
21. حساب Apple Developer باسم المنشأةالحساب مسجل كمنشأة لا كفرد، وأنت صاحب الحساب (Account Holder)، وحسابات الشركة المطورة مضافة كمستخدمين بأدوار محددة.
22. حساب Google Play Console باسم المنشأةالمنشأة مالكة الحساب، وحسابات فريق التطوير مستخدمون بصلاحيات يمكنك تعديلها أو إلغاؤها.
23. التطبيق نفسه داخل حساب المنشأةإن نُشر في حساب المطور فالحل نقل رسمي عبر أدوات المتجرين، لا نشر تطبيق جديد يخسر المستخدمين والتقييمات. تحقق من ظهور التطبيق في قائمة تطبيقات حسابك.
24. مفتاح رفع Android وكلمات مرورهملف المفتاح (Keystore) واسمه المستعار وكلمتا المرور، ومعرفة هل التطبيق مسجل في توقيع Google Play. التحقق: بناء إصدار موقّع ورفعه إلى مسار الاختبار الداخلي من حسابك.
25. توقيع iOS والإمكانات المفعلةمعرف الحزمة (Bundle ID)، والشهادات وملفات التوزيع، والإمكانات المفعلة مثل الإشعارات وتسجيل الدخول بحساب Apple والروابط العامة. التحقق: رفع نسخة إلى TestFlight من حسابك.
26. مفتاح إشعارات Apple (APNs)ملف المفتاح بامتداد p8 مع معرّفه، أو قرار مكتوب بإنشاء مفتاح جديد في حسابك وتحديثه في الخادم أو في خدمة الإشعارات.

ثلاث حقائق من وثائق المتجرين تغيّر طريقة تعاملك مع هذه البنود:

  • مفتاح APNs يُحمَّل مرة واحدة: تنص وثائق حساب مطور Apple على أن المفتاح لا يُحفظ في الحساب ولا يمكن تنزيله مرة أخرى. إن كان عند المطور وحده فاطلبه، أو أنشئ مفتاحًا جديدًا بدل الانتظار.
  • نقل التطبيق في App Store له شروط: بحسب معايير نقل التطبيق في App Store Connect، يجب أن يكون للتطبيق إصدار نُشر في المتجر، وألا يكون في حالة مراجعة أو معالجة، وأن يكون الطرفان قد قبلا أحدث الاتفاقيات. وتوضح Apple أن الطرف الناقل مسؤول عن تسليم الكود وأصول البناء مباشرة للمستلم؛ النقل لا ينقل الكود.
  • النقل في Google Play يحفظ المستخدمين والتقييمات لا التقارير: بحسب مساعدة Play Console عن نقل التطبيقات، ينتقل المستخدمون والتقييمات والمراجعات وبيانات صفحة المتجر، ولا تنتقل تقارير الأرباح والمدفوعات، فحمّلها قبل النقل. وإن كان التطبيق مسجلًا في توقيع التطبيقات في Google Play فيمكن طلب إعادة تعيين مفتاح الرفع إن ضاع أو كُشف، أما مفتاح التوقيع الذي تديره بنفسك خارج هذه الخدمة فلا يُعاد تعيينه إن فُقد.

خطوات النقل نفسها، وما يحدث للمشتريات داخل التطبيق والاشتراكات أثناءه، في مقالة نقل ملكية التطبيق في App Store وGoogle Play إلى منشأتك. وإن كان التطبيق عالقًا في حساب مطور لا يستجيب، فصفحة النشر على المتاجر تشرح كيف يُعالج النقل واستعادة التوقيع.

الاستضافة والنطاق وDNS والشهادات: البنود 27–31

في هذه المجموعة يتكرر نمط واحد: كل شيء يعمل، لكنه مسجل باسم شخص آخر وبطاقة دفع شخص آخر. لا تكتشف ذلك إلا حين تنتهي البطاقة أو يغادر الشخص.

الاستضافة والنطاق: البند وطريقة التحقق
البندكيف تتحقق منه
27. حساب الاستضافة أو السحابة باسم المنشأةالحساب الرئيسي (لا حساب فرعي داخل حساب الشركة المطورة) باسم المنشأة وببطاقة دفعها أو فاتورتها. راجع أول فاتورة تصل إلى منشأتك بعد النقل.
28. النطاق باسم المنشأةبيانات مالك النطاق لدى المسجل هي بيانات المنشأة، والحساب لدى المسجل حسابها، وتاريخ التجديد معروف والتجديد التلقائي مفعّل.
29. سجلات DNS كاملةتصدير كامل لسجلات النطاق، ومعرفة أين تُدار (قد تكون عند مزود غير المسجل). كل سجل غير مفهوم يُسأل عنه قبل التوقيع لا بعده.
30. شهادات SSL وتجديدهامن يصدر الشهادة، وتاريخ انتهائها، وهل تتجدد آليًا. الشهادة التي يجددها المطور يدويًا ستنتهي يومًا دون أن ينتبه أحد.
31. البريد الذي يرسله التطبيقحساب خدمة الإرسال، وسجلات التحقق من المرسل في DNS، والعنوان الذي تُرسل منه رسائل استعادة كلمة المرور والإشعارات.

نقل الاستضافة وقاعدة البيانات بين حسابين دون توقف التطبيق عملية مستقلة لها ترتيبها، تفصلها مقالة نقل الاستضافة والنطاق وقاعدة البيانات من المطور السابق.

المفاتيح والأسرار وحسابات الخدمات ولوحات الإدارة: البنود 32–40

البنود الأخيرة هي الأسهل نسيانًا لأنها موزعة على عشرات اللوحات الصغيرة. ابدأ بالجرد، ثم انقل، ثم غيّر كل ما كان يعرفه غيرك.

الأسرار والخدمات ولوحات الإدارة: البند وطريقة التحقق
البندكيف تتحقق منه
32. سجل الأسرارجدول بكل مفتاح وكلمة مرور: ما الخدمة، وفي أي بيئة، وأين يُستخدم في الكود، ومن يستطيع تغييره. السجل يذكر أماكن الأسرار، لا قيمها.
33. خطة تدوير بعد الاستلامكل سر عرفه المطور السابق يُغيَّر، بترتيب لا يوقف التطبيق: أنشئ الجديد، ثم حدّث الخادم، ثم اختبر، ثم ألغِ القديم.
34. خزنة كلمات المرور والتحقق الثنائيكل كلمات المرور في خزنة تملكها المنشأة، والتحقق الثنائي للحسابات الحساسة مربوط بجوال أو جهاز تابع للمنشأة لا بجوال المطور الشخصي.
35. بوابة الدفعحساب التاجر باسم المنشأة، ومفاتيح الربط في لوحة المنشأة، وعنوان استقبال الإشعارات (Webhook) يشير إلى خادمك. تحقق من أن المبالغ تُحوَّل إلى حساب المنشأة البنكي.
36. خدمات الإشعارات وتتبع الأعطال والتحليلاتمشروع الإشعارات (مثل Firebase) وأداة تتبع الأعطال والتحليلات: المنشأة مالكة، لا مجرد مستخدم مضاف.
37. الرسائل النصية ورموز التحققحساب مزود الرسائل باسم المنشأة، واسم المرسل المسجل، والرصيد وطريقة شحنه. انقطاع هذا الحساب يوقف تسجيل الدخول برمز التحقق كليًا.
38. الخرائط وأي خدمة مدفوعة أخرىحساب الفوترة لكل خدمة، والقيود المفروضة على كل مفتاح، وقائمة الاشتراكات والتراخيص وتواريخ تجديدها ومن يدفعها.
39. حساب مدير أعلى في لوحة التحكمحساب باسم المنشأة بأعلى صلاحية في لوحة إدارة التطبيق، ومعرفة كيف يُنشأ مدير جديد إن فُقد هذا الحساب.
40. تنظيف حسابات الإنتاجقائمة المستخدمين الإداريين في كل لوحة (التطبيق، والخادم، وقاعدة البيانات، والمراقبة): تُحذف حسابات الاختبار، وحسابات المطورين غير المستمرين، وأي كلمة مرور افتراضية.

تفصيل التدوير دون إيقاف الخدمة، وترتيبه حين تتعدد البيئات، في مقالة مفاتيح API والأسرار بعد تغيير المطور. وسؤال «باسم من كل حساب خدمة؟» له مقالة مستقلة: حسابات الخدمات الخارجية في تطبيقك.

أخطاء شائعة تجعل الاستلام شكليًا

  • قبول الكود مضغوطًا في ملف: ملف مضغوط بلا تاريخ ولا وسوم لا يثبت أنه ما يعمل في الإنتاج، ولا يشرح أي قرار.
  • الاكتفاء بإضافتك كمستخدم: إضافتك إلى حساب المتجر أو السحابة كمستخدم ليست ملكية. من يملك الحساب يستطيع إزالتك غدًا.
  • استلام كلمات المرور في محادثة: ثم تركها كما هي. كل كلمة مرور مرت بمحادثة أو بريد تُعامل كمكشوفة وتُغيَّر.
  • توقيع المحضر قبل اختبار البناء: البند 5 هو الذي يكشف النواقص، فلا تجعله بعد التوقيع والدفع.
  • نسيان ما لا يظهر في التطبيق: النطاق، وشهادة SSL، ومزود الرسائل، وحساب البريد. التطبيق يعمل اليوم، ويتوقف يوم التجديد.
  • تدوير كل شيء دفعة واحدة: تغيير كل المفاتيح في ليلة واحدة دون ترتيب يوقف الدفع أو الإشعارات. التدوير بندًا بندًا، مع اختبار بعد كل تغيير.
  • قطع العلاقة قبل انتهاء النقل: نقل التطبيق في المتجر ونقل النطاق يحتاجان تعاون الطرف الآخر. اتفق على موعد لإنهاء الصلاحيات بعد اكتمال النقل، لا قبله.

ما تطلبه من شركة البرمجة وما تجهزه قبل موعد الاستلام

أرسل القائمة إلى الشركة كتابيًا قبل موعد التسليم بوقت كافٍ، واطلب أن يُملأ كل بند بإحدى ثلاث حالات: «مسلَّم ومختبر»، أو «مسلَّم ولم يُختبر»، أو «غير موجود» مع السبب. البند غير الموجود ليس دائمًا تقصيرًا، فقد لا توجد بيئة اختبار أصلًا في مشروع صغير، لكنه يجب أن يكون معلومًا ومكتوبًا.

واطلب من الشركة تحديدًا:

  • جرد الأصول مكتوبًا: كل حساب وخدمة ومستودع، ومالكه الحالي، وما يلزم لنقله.
  • جلسة تسليم معرفي يعرض فيها مطور من الفريق المعمارية ويجيب عن أسئلة فريقك.
  • حضور جلسة اختبار البناء من الصفر (البند 5) للإجابة عما يتعثر، دون أن يلمس لوحة المفاتيح.
  • تنفيذ نقل التطبيق في المتجرين ونقل النطاق من جهتهم بعد أن تجهز حساباتك.
  • تأكيدًا مكتوبًا بإلغاء صلاحياتهم في موعد متفق عليه، أو تحويلها إلى صلاحيات محدودة إن استمر الضمان أو الدعم.

وجهّز من جهتك قبل الموعد:

  • حسابات باسم المنشأة جاهزة لاستقبال النقل: حساب مؤسسي للمستودعات، وحسابا المطور في المتجرين، وحساب الاستضافة. حساب Apple للمنشآت يحتاج رقم D-U-N-S، فاطلبه مبكرًا.
  • خزنة كلمات مرور للمنشأة، وجوالًا أو جهازًا تابعًا لها للتحقق الثنائي.
  • من سيختبر: مطور من فريقك، أو شركة ستستلم الصيانة، أو جهة مراجعة مستقلة.
  • العقد والمتطلبات الأصلية، لتقارن ما سُلّم بما اتُّفق عليه.
  • نسخة من هذه القائمة بعمود للحالة وعمود للملاحظات، لتصبح هي محضر الاستلام.

في الاستلام الذي نتولاه، نعمل بالترتيب نفسه: حصر الأصول، واستعادة الصلاحيات وتغيير كلمات المرور، ونقل الحسابات إلى ملكية المنشأة، ونسخة احتياطية كاملة قبل أي تغيير، كما توضح صفحة استلام مشروع برمجي متعثر. وحين نسلّم نحن مشروعًا، يكون الكود في مستودع باسم منشأتك والتطبيق منشورًا بحساباتها منذ البداية، كما في الأسئلة الشائعة.

الخلاصة: لا تدفع مقابل ملف، ادفع مقابل استقلال

قيمة هذه القائمة ليست في عدد بنودها، بل في سؤال واحد تختبره: هل يستطيع فريقك أن يبني التطبيق وينشره ويستعيد بياناته ويجدد حساباته دون الشركة السابقة؟ إن كانت الإجابة نعم لكل مجموعة، فقد استلمت. وإن كانت «ليس بعد»، فاكتب ما ينقص في المحضر بموعد محدد، واربط الدفعة الأخيرة به.

إن كان المشروع قد توقف قبل أن تصل إلى مرحلة الاستلام، أو لا تعرف أصلًا ما الذي تملكه منه، فابدأ بالجرد والتقييم قبل أي قرار. اطلب تقييم حالة المشروع لنبدأ بقائمة الأصول ومراجعة الوصول، أو أرسل تفاصيله عبر طلب استلام مشروع.

أسئلة شائعة

لا. الملف المضغوط لا يثبت أنه الإصدار العامل في الإنتاج، ولا يحمل تاريخ التعديلات ولا الوسوم. اطلب مستودعًا في حساب تملكه منشأتك بتاريخه الكامل، ثم اختبر البناء منه على جهاز نظيف.

الأفضل نقل رسمي عبر أدوات المتجرين، لأن النشر من جديد يعني تطبيقًا جديدًا بلا مستخدمين ولا تقييمات. النقل في Apple له شروط، منها أن يكون للتطبيق إصدار منشور وألا يكون قيد المراجعة، ويحتاج تعاون صاحب الحساب الحالي.

اطلب من الشركة التي ستتولى الصيانة أو من جهة مراجعة مستقلة أن تنفذ اختبار البناء من الصفر وتجربة استعادة النسخة الاحتياطية. الشركة المسلِّمة لا تصلح لهذا الاختبار، لأنها تعرف ما ليس مكتوبًا.

نعم لكل ما عرفه المطور السابق، لكن بترتيب لا يوقف التطبيق: أنشئ المفتاح الجديد، ثم حدّث الخادم، ثم اختبر، ثم ألغِ القديم. التغيير الجماعي في ليلة واحدة قد يوقف الدفع أو الإشعارات.

بعد توقيع محضر استلام يذكر حالة كل بند. البنود الحرجة، مثل المستودع وحسابات المتاجر ومفتاح التوقيع والنطاق وتجربة الاستعادة، يجب أن تكتمل قبله، والبنود الأخرى يمكن أن تُكتب بموعد استكمال محدد.

وثّق ما طلبته كتابيًا وما رُفض، وابدأ بما تستطيع استعادته من جهتك، مثل النطاق عبر المسجل والحسابات المسجلة باسم المنشأة. ثم قيّم ما يمكن استعادته من الخادم وملفات البناء قبل أي قرار، والجوانب التعاقدية تُراجع مع مستشار قانوني.

خدمات وصفحات مرتبطة

استلام المشاريعاستلام مشروع متعثراستلام مشاريع التطبيقات والأنظمة المتعثرة من شركات أو مطورين آخرين: تقييم الكود وقاعدة البيانات والمعمارية والبنية والأمن ووضع…استلام المشاريعمراجعة الكود وتدقيق المعماريةمراجعة مستقلة للكود المصدري والمعمارية لتطبيقك أو نظامك: الجودة، والأمن، وقاعدة البيانات، والأداء، والمكتبات، والاختبارات، والتوثيق.خدمةالنشر على المتاجرنشر التطبيقات على App Store وGoogle Play بحساب منشأتك: حسابات المطور، والتوقيع والشهادات، وTestFlight والاختبار الداخلي، وصفحة المتجر…خدمةصيانة ودعم التطبيقاتعقود صيانة ودعم التطبيقات والأنظمة: إصلاح الأخطاء، والمراقبة، والتوافق مع إصدارات iOS وAndroid، وتحديثات المكتبات والأمن، وتحسين الأداء،…صفحةاطلب عرض سعرأرسل تفاصيل مشروعك في ست خطوات: نوع المشروع والمنصات والمزايا وما لديك من متطلبات أو تصاميم أو كود،…

اقرأ أيضًا

تغيير شركة التطوير: خطة انتقال بلا توقفقررت تغيير شركة تطوير تطبيقك؟ خطة انتقال من ست مراحل: التحضير، والإخطار، وفترة التداخل، والتجميد، ويوم التحويل، وأول إصدار، مع جدول مسؤوليات للأطراف.كم يكلف استكمال تطبيق توقف في منتصفه؟لديك تطبيق نصف مكتمل؟ اعرف لماذا لا تعطيك الشركات رقمًا مباشرًا، وما الذي يحدد تكلفة الاستكمال، بمثال افتراضي وسلّم لقياس اكتمال كل ميزة.شركة البرمجة لم تكمل التطبيق: خطوات الأسبوع الأولتوقفت شركة البرمجة والتطبيق لم يكتمل؟ خطوات الأسبوع الأول بالأولوية: تأمين الحسابات، والنسخ الاحتياطية، والجرد، والتوثيق، ثم التقييم المستقل وقرار الاستكمال.

استلمت المشروع ولست متأكدًا أنه كامل؟

نبدأ بجرد الأصول ومراجعة الوصول والكود، ونسلمك تقريرًا بما استلمته فعلًا وما ينقص وما يجب نقله إلى منشأتك.

اطلب مراجعة الاستلاماحجز اجتماعًا تقنيًا
اطلب عرض سعر