دليل إطلاق التطبيقات: iOS و Android لمصر والخليج
معظم مشاريع التطبيقات مش بتفشل في مرحلة التطوير — بتفشل في الـ 90 يوم بعد الإطلاق. دي الحاجات اللي لازم تضبطها قبل وأثناء وبعد ما تطلع للناس.
التطبيق بتاعك عدى QA. الفريق احتفل. وبعد تلات أسابيع من الإطلاق، المستخدمين النشطين يوميًا وقفوا عند 40 نفر — معظمهم من فريقك بيتيستوا التطبيق. الموضوع ده بيتكرر على طول في مصر وفي دول الخليج، ونادرًا ما يكون السبب كود وحش.
المشاكل دايمًا بتيجي من قبل: اختيار تكنولوجيا غلط، تقدير وقت رفع التطبيق بشكل أقل من اللازم، مفيش حلقة ريتينشن، وميزانية ما بعد الإطلاق بتساوي صفر تقريبًا. خلينا نتكلم في كل واحدة على حدة.
Native ولا Flutter ولا Web Wrapper: القرار الحقيقي
السؤال مش أنهي تكنولوجيا "أحسن" — السؤال أنهي واحدة بتتناسب مع ميزانيتك وقايمة الفيتشرز بتاعتك وقدرتك على الصيانة بعد كده.
- Native iOS + Android: كودبيسين منفصلين. أفضل أداء وأكبر وصول لـ APIs الجهاز. متوقع وقت وتكلفة أعلى بـ 40–60% مقارنة بالبناء الـ cross-platform. يستاهل لو بتبني حاجة فيها كاميرا تقيلة أو صوت real-time أو تكامل مع Bluetooth.
- Flutter: كودبيس واحد، متجرين. Framework جوجل اتطور بسرعة — معظم شركات التطوير في مصر والخليج دلوقتي بتستخدمه كـ default. الأداء قريب جدًا من Native في الغالبية العظمى من تطبيقات الأعمال. هتوفر 3–5 أسابيع في مشروع متوسط الحجم.
- React Native: نفس منطق الـ cross-platform زي Flutter. مجتمع أكبر، مكتبات third-party أكتر، وصداع صيانة بنكهة JavaScript أكتر شوية. اختيار كويس لو فريقك أصلًا شغال بـ JS.
- Web Wrapper (Capacitor / Cordova): تلف موقع ويب في شكل تطبيق. رخيص في الأول، مؤلم بعد كده. سلوك الـ Scroll حاسس بيه غلط، الـ offline support معركة مستمرة، وفريق مراجعة Apple بقى أعدوانية في رفض التطبيقات اللي هي في الأساس مواقع ويب موبايل.
لمعظم الشركات الصغيرة والمتوسطة في مصر وتطبيقات المنطقة في الخليج — تتبع التوصيل، الحجوزات، الأدوات الداخلية، برامج الولاء — Flutter بيدي أفضل توازن. تحليل أعمق لإمتى كل تكنولوجيا بتستاهل يستحق القراءة قبل ما تعمل briefing لأي شركة تطوير.
التايم لاين الواقعي (مش نسخة عرض المبيعات)
تطبيق Flutter متكامل الـ scope بفيتشرز عادية — auth، بروفايل مستخدمين، push notifications، backend API، وأدمن بانيل — بياخد من 14 لـ 18 أسبوع من أول التوقيع على الـ brief لحد رفعه على App Store. مش 6 أسابيع. مش 8 أسابيع، إلا لو اتشال scope كبير أو الفريق ضخم بشكل غير عادي.
تقريبًا بتتوزع كده:
- Discovery + Architecture: أسبوعين. Wireframes، تصميم الـ API، مخطط قاعدة البيانات.
- Sprints التطوير الأساسية: 8–10 أسابيع. Backend + موبايل شغالين بالتوازي.
- QA + اختبار الأجهزة: أسبوعين. اتيست على أجهزة حقيقية، مش simulators بس. تنوع هاردوير Android في مصر يعني لازم تتيست على أجهزة Tecno وSamsung متوسطة المستوى، مش الفلاجشيب بس.
- رفع App Store + Play Store: أسبوع لـ أسبوعين. Apple بتاخد 1–3 أيام للمراجعة في الغالب، بس ممكن تطلب تعديلات تضيف أسبوع. Google عادةً 24–48 ساعة.
نطاقات التكلفة: مصر مقابل الخليج
التطوير من القاهرة أوفر بشكل واضح من التوظيف في الرياض أو دبي أو الدوحة — من غير فرق حقيقي في الجودة لو اخترت الشركة الصح.
- مصر (القاهرة): تطبيق Flutter متوسط التعقيد بيتراوح عادةً بين 350,000–700,000 جنيه (تقريبًا 7,000–14,000 دولار بالأسعار الحالية). تطبيقات enterprise بتكاملات custom ممكن توصل لـ 1.2 مليون جنيه+.
- شركة في الخليج: نفس الـ scope ممكن يجي بـ 25,000–60,000 دولار. بتدفع مقابل account management محلي وراحة التوقيت.
- فرق فريلانس: أرخص في الأول، بس محدش مسؤول عن الـ architecture. لما حاجة تتعطل بعد ستة شهور من الإطلاق، المسؤولية بتضيع في الهوا بسرعة.
لو تطبيقك هيخدم مستخدمين في الخليج بس عملياتك مبنية في مصر، شركة قاهرية بخبرة مشاريع خليجية هي الاختيار العملي في الغالب. فريق ProgMine بيشتغل مع عملاء في السوقين وشحن تطبيقات على App Store وPlay Store لشركات مصرية وخليجية.
دليل رفع التطبيق على App Store
مراجعة Apple بترفض تقريبًا 40% من أول رفعة — في الغالب لأسباب متوقعة. اتفادى إيه:
- رابط سياسة الخصوصية لازم يكون شغال ويتفتح قبل ما ترفع. مش "قريبًا."
- لو تطبيقك بيطلب صلاحيات (كاميرا، موقع، جهات الاتصال)، كل صلاحية لازم يكون ليها purpose string واضح. عبارات مبهمة زي "لتحسين تجربتك" بتتسبب في رفض.
- المشتريات داخل التطبيق لازم تستخدم نظام الدفع الخاص بـ Apple. مفيش استثناءات، مفيش تحويل لـ web checkout للمنتجات الرقمية.
- الـ Screenshots لازم تتطابق مع الـ UI الفعلي تمامًا. بعت موكاب بيختلف عن البيلد ده رفض سريع.
- اتيست تطبيقك على أقدم إصدار iOS ناوي تدعمه — عادةً iOS 15 أو 16. الـ Crashes على الأجهزة القديمة بتسبب رفض حتى لو جهازك الحديث شغال تمام.
Google Play أقل صرامة بس شددت قواعدها حوالين إعلانات سلامة البيانات. املأ جزء Data Safety بدقة — الفحوصات الآلية عند جوجل دلوقتي بترصد التناقضات بين الـ network traffic الحقيقي لتطبيقك وإيه اللي صرحت بيه.
إمتى تضيف المدفوعات والـ Push Notifications والـ Offline Mode
تلات فيتشرز كل عميل بيطلبهم في الآخر — وبيضيفوا تعقيد أكتر بكتير مما بيبانوا.
المدفوعات
في مصر، Fawry وPaymob بيغطوا معظم حالات الاستخدام. لتطبيقات الخليج، Tap Payments وStripe (في الأماكن المتاحة) هما المعيار. دمج المدفوعات بيضيف 2–3 أسابيع تطوير وأسبوع لـ أسبوعين اختبار Compliance. متربطوش بعد الإطلاق — الـ backend architecture لازم يحسب ليها من أول يوم.
Push Notifications
Firebase Cloud Messaging بيتعامل مع iOS وAndroid. الجانب التقني مباشر. الصعب هو استراتيجية الإشعارات — معظم التطبيقات بتزعج المستخدمين لدرجة إنهم بيوقفوا الإشعارات في أسبوعين لأنها بتتبعت كتير وعلى طول بشكل عام. خطط لمنطق الإشعارات كقرار product، مش تذكرة dev.
Offline Mode
الـ offline support الحقيقي — اللي فيه التطبيق بيقرأ ويكتب بيانات من غير اتصال، وبعدين يعمل sync لما يرجع النت — ممكن يضيف 3–4 أسابيع تطوير. معقد فعلًا. ابنيه بس لو مستخدميك هيكونوا بانتظام في بيئات ضعيفة الاتصال. تطبيقات الخدمة الميدانية والـ Logistics محتاجاها في الغالب. تطبيق حجز مطاعم على الأرجح لأ.
إزاي تختار شركة التطوير
أربع حاجات بتفرق بين الشركات الموثوقة واللي بتختفي بعد التسليم:
- بيوريوك النسخة الـ production من تطبيقات حية بنوها، مش Screenshots بجودة Dribbble بس. نزّل التطبيق. استخدمه. شوف أداءه.
- بيكتبوا الـ scope قبل ما يقدموا السعر. أي شركة بتديك سعر في الاجتماع الأول من غير ما تفهم متطلباتك، هتشحن أكتر أو هتسلم أقل.
- بيتكلموا عن دعم ما بعد الإطلاق من الأول. Hosting، صيانة API، تحديثات نظام التشغيل — iOS بتطلع update كبير كل سبتمبر وبتكسر حاجة في تقريبًا كل تطبيق. إيه الخطة؟
- بيعارضوا أفكارك. شركة موافقة على كل حاجة بتقولها هي شركة مش عملت الموضوع ده كفاية مرات عشان تعرف إيه اللي بيسبب مشاكل.
لو لسه بتحاول تفهم التطبيق بتاعك هيعمل إيه بالظبط قبل ما تعمل briefing لحد، المقال ده عن المبادئ الأساسية لتخطيط تطبيقات الموبايل نقطة بداية كويسة.
الأخطاء اللي بتقتل التطبيق بهدوء بعد الإطلاق
الأكثر شيوعًا، بالترتيب حسب كام مرة بنشوفهم:
- مفيش analytics متحطة. أنت بتطير عميان على أنهي فيتشرز الناس بتستخدمها فعلًا.
- مفيش Crash reporting (Firebase Crashlytics مجاني — مفيش عذر).
- الـ App Store listing فاضل بوصف يوم الإطلاق على طول. حدّثه لما بتشحن فيتشرز كبيرة. الـ Screenshots لازم تعكس شكل التطبيق الفعلي.
- ميزانية صفر لاستقطاب المستخدمين. بناء التطبيق كان البداية، مش النهاية.
- تجاهل التقييمات. رد على تقييم نجمة واحدة — خصوصًا لو كان بناء — ساعات أحسن لمعدلات التحويل من أي نسخة تسويقية.
لنظرة أشمل على إزاي قرارات المنتج الرقمي بتترابط — من التطبيق للويب للـ backend — سؤال البناء مقابل الشراء ينطبق على الموبايل زي ما بينطبق على برامج Enterprise.
عايز تتكلم؟
لو بتحسب تطبيق موبايل لمصر أو الخليج — سواء كنت بتبدأ من الصفر أو بتنقذ مشروع واقف — احنا مبسوطين نبص على اللي عندك ونديك تقييم صريح. من غير عرض تقديمي، من غير proposal قبل ما نفهم المشكلة فعلًا. تواصل معنا عن طريق progmine.com وخلينا نتكلم بجد.
هل تريد التواصل؟
لديك مشروع أو أسئلة عن خدماتنا؟ تواصل معنا.