نبني تطبيقات الجوال بـ Flutter، فيخرج iOS وAndroid من قاعدة كود واحدة باختبارات واحدة وعملية إصدار واحدة — قرار اتخذناه لمنتجنا قبل أن نوصي به أحدًا.
البناء المنفصل لـ iOS وAndroid يضاعف العمل الهندسي، لكن الكلفة الحقيقية تأتي لاحقًا: قائمتا مهام، وطابورا أخطاء، وميزات تتباعد بهدوء حتى يصبح مستخدمو أندرويد على منتج مختلف عن مستخدمي آيفون.
وفي الغالبية الساحقة من تطبيقات الأعمال — أي شيء جوهره شاشات ونماذج وإشعارات واتصال بالشبكة — لا يشتري هذا الثمن شيئًا يلاحظه المستخدم.
Flutter يعطي قاعدة كود واحدة واختبارات واحدة وإصدارًا واحدًا، دون الإحساس البطيء غير الأصلي الذي جعل الأدوات السابقة تنازلًا. تطبيقنا نفسه مبني بهذه الطريقة — العربية والإنجليزية مصانتان جنبًا إلى جنب مفتاحًا بمفتاح، ومعهما اختبارات تكامل تشغّل الواجهة الحقيقية على جهاز.
كل بند هنا شيء بنيناه وما زلنا نشغّله بأنفسنا — لا خدمة قرأنا عنها فقط.
قاعدة كود واحدة، وأداء مُصرَّف أصلي، ومكان واحد لإصلاح أي خطأ. تبقى المنصتان متطابقتين فعلًا لأن هناك واحدة فقط تُصان.
تسجيل الأجهزة، وتحديث الرموز، وإدارة الأذونات، وفصل الجهاز عند تسجيل الخروج. الإشعارات تفشل بصمت — لا شيء ينهار، الإشعار ببساطة لا يصل، ولا أحد يبلّغ عن رسالة لم يعرف أصلًا أنها أُرسلت.
تخزين مؤقت يمنع أن يكون بدء التشغيل شاشة فارغة، واتصال يعيد ربط نفسه حين تعود الإشارة، وإعادة محاولة لأي شيء فشل، ورسالة معرَّبة تقول ما الذي حدث — لأن هاتفًا على بيانات الجوال يفشل أكثر بكثير من جهاز مكتبي.
الواجهة كلها تنعكس كما ينبغي — التنقّل والإيماءات والأيقونات والخطوط — مع ملفَّي موارد عربي وإنجليزي يُصانان جنبًا إلى جنب. ولتطبيق يخدم سوق الإمارات أو السعودية، حيث يقرأ موظفو الشركة الواحدة وعملاؤها باللغتين، هذا هو الحد الأدنى لا ميزة إضافية.
الرموز داخل مخزن مفاتيح النظام — Keychain على iOS وEncryptedSharedPreferences على Android — وتجديد واحد مشترك للجلسة كي لا تُسقِط الطلبات المتزامنة الجلسةَ، وجلسات تنتهي حين ينبغي، بدل بيانات دخول في تفضيلات مكشوفة.
اختبارات تكامل تشغّل الواجهة الحقيقية — تسجيل الدخول، وتسجيل الإشعارات، والإشعارات نفسها، والمسارات الأساسية — على جهاز حقيقي أو محاكٍ، فيظهر الانحدار كتشغيل فاشل لا في المراجعة.
توقيع الإصدار والتصاريح وأصول صفحة المتجر ولقطات الشاشة — جاهزة لتطبيقنا، ونتولّاها عنك في مشروعك، بما في ذلك حالات الرفض التي يجمعها أول طلب نشر لأسباب مملّة.
التطبيق عادةً هو العُشر الظاهر من العمل. نبني الواجهة البرمجية ونموذج البيانات ولوحة الإدارة خلفه، بدل تسليمك عميلًا لا يجد ما يحدّثه.
الترتيب نفسه في كل مشروع، أيًّا كانت التقنية المستخدمة.
بعض الأشياء أفضل في المتصفح، ونقول ذلك مبكرًا — تطبيق أصغر يفتحه الناس أثمن من تطبيق كبير يُثبَّت مرة ويُنسى.
تصلك نسخ على هاتفك طوال المشروع، لا عرض في النهاية. قراءة المسار على جهاز حقيقي تخبرك بما لا يخبرك به أي تصميم.
حسابات المتاجر والتوقيع والصفحات والنشر — ثم تسليم عملية التحديث كي لا تكون معتمدًا علينا لإطلاق إصلاح.
الأسئلة التي تُطرح فعلًا في أول مكالمة.
التطوير الأصلي يستحق كلفته حين يقوم التطبيق على قدرات خاصة بالمنصة: عمل مكثّف بالكاميرا أو الواقع المعزّز، أو تكامل عميق مع النظام، أو معالجة خلفية مستمرة. أما تطبيقات الأعمال المبنية من شاشات ونماذج وإشعارات وواجهة برمجية، فقاعدة كود Flutter واحدة تؤدي العمل الذي كان سينقسم على قاعدتين أصليتين — قائمة مهام واحدة، واختبارات واحدة، وإصدار واحد. سنخبرك في أي الحالتين أنت.
نعم، ونفضّل ذلك. يجب أن يعيش التطبيق في حسابَي Apple وGoogle الخاصين بك منذ البداية حتى لا تكون الملكية موضع سؤال أبدًا. وسنرشدك لإنشائهما إن لم تكن فعلت.
نستطيع استلام صيانته أو تطويره. وكما في عمل الويب، نبدأ بمراجعة ونقول لك بصراحة أي المسارين أرخص، الاستكمال أم إعادة البناء — بما في ذلك حين تكلّفنا الإجابة المشروع الأكبر.
نعم. تطبيقنا نفسه يُشحن بملفَّي موارد عربي وإنجليزي وواجهة معكوسة بالكامل. هذا عمل اعتيادي عندنا لا طلب خاص.
أخبرنا من يفتحه وما الذي يحتاج إنجازه. نعود إليك بنطاق وتقدير، وبإجابة صادقة عمّا إذا كان ينبغي أن يكون تطبيقًا أصلًا.
كل مشروع يبدأ بمكالمة لتحديد النطاق ثم تقدير مكتوب، قبل كتابة أي سطر برمجي. ولا نطلب عقدًا مسبقًا لمجرد الحديث.