إعادة تصميم تطبيقات iOS القديمة: دليل التحديث 2026
متى تحتاج إلى إعادة تصميم تطبيقات iOS القديمة
تحتاج تطبيقات iOS القديمة إلى إعادة تصميم عند تزامن ثلاث علامات تحذيرية: كود قديم يصعب صيانته، تراجع في الأداء مع أنظمة iOS الحديثة، وانخفاض تقييمات المستخدمين إلى ما دون 4.0 نجمة. عندما تظهر هذه العلامات الثلاث معًا، تصبح إعادة التصميم أولوية عالية وليست خيارًا مؤجلًا. يجد الممارسون عادةً أن انخفاض التقييم دون 4.0 نجمة هو المؤشر الأوضح على تراكم مشكلات الكود القديم وضعف الأداء في آنٍ واحد. تجاهل هذه الإشارات يعني خسارة العملاء لصالح منافسين يقدمون تجربة أسرع وأنظف.
تاريخ النشر: يناير 2026. هذا الدليل مبني على ممارسات هندسة برمجيات iOS الشائعة والوثائق الرسمية من Apple، ويستهدف المطورين وأصحاب الأعمال في مصر والخليج. الأرقام الواردة أدناه منسوبة إلى مصادرها، وما لا يمكن التحقق منه مباشرةً يُقدَّم كإرشاد عام لا كإحصاء قاطع.
علامات التقادم التقني
أبرز علامة على تقادم تطبيق iOS هي الاعتماد على Objective-C دون طبقة Swift حديثة، إلى جانب استخدام UIKit فقط دون دعم SwiftUI. التطبيقات التي بُنيت قبل 2020 تقع غالباً في هذا الفخ، ما يجعل إضافة ميزات جديدة بطيئة ومكلفة. مكتبات خارجية متوقفة عن التحديث، أو حزم CocoaPods قديمة، تزيد من صعوبة توافق التطبيق مع أدوات Xcode الحديثة. يلاحظ الممارسون عملياً أن الدين التقني (Technical Debt) — وهو تراكم قرارات هندسية سريعة تؤجل التكلفة إلى المستقبل — يصبح عبئاً حقيقياً على النمو حين يستغرق فريق التطوير أسابيع لإضافة ميزة كانت تُنجز في أيام؛ فالفارق بين الأيام والأسابيع هو المؤشر الأوضح على أن البنية التقنية باتت تعوق التوسع بدلاً من دعمه.
من الناحية العملية، يمكن قياس التقادم عبر مؤشرات ملموسة: نسبة الكود المكتوب بـ Objective-C مقابل Swift، عدد الاعتماديات (Dependencies) التي لم تُحدَّث منذ أكثر من عامين، وعدد التحذيرات (Warnings) التي يُصدرها Xcode عند بناء المشروع. في التطبيق المعتاد الذي بدأ التقادم، تجد مئات التحذيرات المتعلقة بواجهات برمجية مهجورة (Deprecated APIs) — وهي إشارة مبكرة إلى أن التوافق مع إصدار iOS القادم في خطر.
مشاكل الأداء والتوافق مع أنظمة iOS الجديدة
توافق التطبيق مع أحدث إصدارات iOS هو العامل الأكثر تأثيراً في استقرار التطبيقات القديمة: أي تطبيق لم يُحدَّث منذ إصدارين معرّض لأعطال مفاجئة أو رفض من متجر App Store عند التحديث. فمع كل إصدار سنوي من Apple تتغير متطلبات الواجهات والأمان، كما توثّقه Apple في إرشادات واجهة الإنسان (Human Interface Guidelines). أوقات التحميل الطويلة ترفع معدل التخلي، خصوصاً على الأجهزة الأحدث ذات الشاشات مثل iPhone 15 وما بعده، التي لا يتكيّف معها التصميم القديم المبني على أبعاد ثابتة. باختصار، بطء التحميل وعدم مواكبة إصدارين متتاليين من iOS هما أبرز سببين لفقدان المستخدمين.
الجانب التقني هنا يستحق التوضيح: التطبيقات القديمة كثيراً ما تعتمد على تخطيطات (Layouts) مبنية بإطارات ثابتة (Frame-based Layout) بدلاً من قيود التخطيط التلقائي (Auto Layout) أو نظام التخطيط المرن في SwiftUI. هذا يجعل التكيف مع تنوع أحجام الشاشات — من iPhone SE إلى Pro Max — عملية يدوية مرهقة، وهي أحد أكبر مصادر الأعطال البصرية بعد كل إصدار جهاز جديد.
تراجع تقييمات المستخدمين
تراجع تقييمات المستخدمين إلى ما دون 4.0 نجمة هو مؤشر مباشر على أن التطبيق بحاجة إلى إعادة تصميم لا إلى ترقيعات جزئية. مراجعات المستخدمين تكشف هذه الحاجة مبكراً: شكاوى متكررة حول البطء أو الأعطال أو واجهة غير مريحة تشير إلى فجوة بين توقعات المستخدم والتجربة الفعلية. يجد الممارسون عادةً أن التطبيق الذي يفقد شريحة كبيرة من مستخدميه النشطين خلال عام واحد يعاني على الأرجح من مشكلات تصميم وأداء عميقة لا تحلها الإصلاحات السطحية. متابعة معدل الاحتفاظ (Retention) شهرياً تمنحك صورة رقمية واضحة: انخفاض معدل العودة بعد 30 يوماً بشكل حاد غالباً ما يجعل إعادة التصميم الكاملة استثماراً ضرورياً لا خياراً مؤجلاً. باختصار، المؤشرات الحاسمة هي تقييم دون 4.0 نجمة، وفقدان متسارع للمستخدمين النشطين، وتراجع واضح في معدل العودة بعد 30 يوماً.
ما هي مخاطر إبقاء الكود القديم Objective-C دون تحديث؟
إبقاء الكود القديم Objective-C دون تحديث يعرّض تطبيق iOS لثلاثة مخاطر مباشرة. الأول: ثغرات أمنية تهدد بيانات عملائك. الثاني: تكلفة صيانة متصاعدة تلتهم ميزانيتك. الثالث: رفض Apple لتحديثاتك على App Store. في الحالات المعتادة، تجاهل هذه المخاطر لا يوقف نمو التطبيق فحسب، بل قد يخرجه من السوق نهائياً.
الثغرات الأمنية في الأكواد القديمة
الأكواد المكتوبة قبل 2018 غالباً ما تفتقر إلى تقنيات الأمان الحديثة مثل App Transport Security المشددة وتشفير البيانات المحلية عبر أحدث إصدارات CryptoKit. الأكواد القديمة تفتقر كذلك إلى ممارسات مثل تثبيت الشهادات (Certificate Pinning) والتخزين الآمن للمفاتيح في Keychain بالطرق الحديثة. بالنسبة لتاجر يخزّن بيانات الدفع أو معلومات العملاء، ثغرة واحدة قد تعني غرامات تنظيمية وفقدان ثقة العملاء بشكل لا يمكن إصلاحه.
ملاحظة منهجية حول التحقق: يُتداول أحياناً أن التطبيقات غير المحدّثة "أكثر عرضة للاختراق بنسبة تفوق 60%"، غير أننا لم نتمكن من نسب هذا الرقم إلى تقرير أمني رسمي محدد بتاريخ ومصدر قابل للتحقق، لذا نتجنب تقديمه كإحصاء قاطع. الأدق منهجياً أن نقول: الاعتماد على واجهات برمجية أمنية مهجورة يزيد سطح الهجوم (Attack Surface) بشكل ملموس، والاعتماد على مكتبات طرف ثالث متوقفة عن التحديث يترك ثغرات معروفة (CVEs) دون ترقيع. للاطلاع على المتطلبات الأمنية الرسمية لكل إصدار، راجع وثائق الأمان من Apple.
صعوبة الصيانة وارتفاع التكلفة
مطورو Objective-C أصبحوا أقل توفراً في سوق مصر والخليج، إذ تحوّل معظم المواهب الجديدة إلى Swift منذ أن جعلتها Apple لغة التطوير الأساسية. ندرة المطورين تميل إلى رفع أجورهم، وكل تعديل بسيط يستغرق وقتاً أطول بسبب تعقيد الكود المتراكم. حساب سريع من واقع الممارسة: صيانة تطبيق قديم على مدى ثلاث سنوات قد تقترب من تكلفة إعادة تصميمه بالكامل، مع نتائج أضعف وقدرة أقل على إضافة الميزات.
لتقدير هذه المقايضة بموضوعية، يُنصح بحساب "تكلفة الملكية الإجمالية" (Total Cost of Ownership): مجموع أجور الصيانة السنوية + كلفة الفرص الضائعة من الميزات المؤجلة + مخاطر التوقف عن العمل. عند مقارنة هذا المجموع على أفق ثلاث سنوات بتكلفة إعادة التصميم لمرة واحدة، تتضح الجدوى بأرقام قابلة للنقاش مع صاحب القرار بدلاً من ادعاءات عامة.
رفض Apple للتحديثات
Apple تحدّث متطلبات App Store دورياً وتفرض دعم أحدث SDK. من المعتاد أن تشترط Apple رفع التطبيقات مبنيةً على أحدث إصدار SDK متاح، والتطبيقات التي تعتمد على مكتبات مهجورة قد تُرفض تحديثاتها. تطبيق لا يستطيع نشر تحديث هو تطبيق ميت عملياً — لا إصلاح لأخطاء، ولا توافق مع أجهزة iPhone الجديدة، وتراجع تدريجي في التقييمات. للاطلاع على المتطلبات المحدّثة والمواعيد الرسمية، ارجع دائماً إلى إرشادات مراجعة App Store الرسمية، فهي المرجع الوحيد الموثوق لمتطلبات الرفع في أي سنة.
الخلاصة العملية: كلما طال إبقاء الكود القديم، ارتفعت تكلفة الترحيل لاحقاً. الاستثمار في التحديث المبكر أقل تكلفة وأكثر أماناً من انتظار لحظة الأزمة.
استراتيجيات التحديث: إعادة كتابة كاملة أم تحديث تدريجي؟
تعد إعادة تصميم تطبيقات iOS القديمة من أبرز الاتجاهات في 2026.
إعادة تصميم تطبيقات iOS القديمة تنقسم إلى مسارين رئيسيين: إعادة الكتابة الكاملة (Rewrite) التي تبدأ من الصفر بلغة Swift الحديثة، والتحديث التدريجي (Incremental Migration) الذي يحوّل الكود القديم على مراحل. لكل نهج مخاطر وتكاليف مختلفة تعتمد على حجم التطبيق وميزانيتك.
الترحيل من Objective-C إلى Swift/SwiftUI
الانتقال من Objective-C إلى Swift أصبح توجهاً راسخاً، إذ توصي Apple بـ SwiftUI كإطار حديث لبناء الواجهات عبر منصاتها. Swift يميل إلى تقليل عدد أسطر الكود مقارنة بـ Objective-C ويحسّن الأمان بفضل نظام التحقق من الأنواع الصارم (Type Safety) والتعامل الآمن مع القيم الفارغة (Optionals). الميزة العملية: يمكن دمج Swift و Objective-C داخل نفس المشروع عبر جسر Bridging Header، ما يسمح بترحيل الوحدات واحدة تلو الأخرى دون توقف التطبيق عن العمل. لفهم منهجية التبني الرسمية، راجع وثائق SwiftUI من Apple.
من مقايضات هذا المسار: SwiftUI أحدث من UIKit ولا يزال بعض المكونات المتقدمة يتطلب العودة إلى UIKit عبر جسر (UIViewRepresentable). لذا يميل الممارسون إلى نهج هجين يبني الشاشات الجديدة بـ SwiftUI مع إبقاء الشاشات المعقدة على UIKit مؤقتاً، بدلاً من الترحيل الكامل دفعة واحدة.
نهج الوحدات المعيارية (Modular Migration)
تقسيم التطبيق إلى وحدات معيارية مستقلة يتيح تحديث شاشة الدفع أو نظام تسجيل الدخول أولاً، ثم الانتقال للوحدات الأقل أهمية لاحقاً. تعتمد الفرق التقنية في مصر والخليج هذا النهج لأنه يبقي التطبيق منشوراً على App Store طوال فترة التحديث، ويسمح باختبار كل وحدة على شريحة محدودة من المستخدمين قبل الإطلاق الكامل عبر أدوات مثل TestFlight.
مقارنة المخاطر والتكاليف
| المعيار | إعادة كتابة كاملة | تحديث تدريجي |
|---|---|---|
| المدة | 6–12 شهراً | 3–8 أشهر |
| المخاطرة | عالية (توقف محتمل) | منخفضة |
| التكلفة الأولية | أعلى (تكلفة مركّزة مقدماً) | موزّعة على مراحل |
| الأنسب لـ | تطبيقات صغيرة أو كود متهالك | تطبيقات كبيرة نشطة |
ملاحظة: نطاقات المدة أعلاه تقديرية استرشادية تعتمد على حجم التطبيق وعدد الشاشات ومدى الديون التقنية، وليست ضماناً؛ الرقم الدقيق يظهر بعد تدقيق تقني للكود الفعلي.
القاعدة العملية: إذا كان تطبيقك يخدم آلاف المستخدمين يومياً، اختر التحديث التدريجي لتجنب مخاطر الانقطاع. أما إذا كان الكود القديم صغيراً وصعب الصيانة، فإعادة الكتابة الكاملة بـ SwiftUI غالباً أوفر على المدى الطويل. من الممارسات الجيدة أن يبدأ أي مشروع بتدقيق تقني (Technical Audit) يحدد أي المسارين يناسب وضع التطبيق وميزانيته قبل كتابة سطر كود واحد.
خطوات إعادة تصميم UX/UI للتطبيق القديم
إعادة تصميم واجهة التطبيق القديم تبدأ بفهم كيف يستخدم عملاؤك التطبيق فعلياً، لا بافتراض ما يحتاجونه. الفرق بين إعادة تصميم ناجحة وأخرى فاشلة يكمن في ثلاث مراحل متسلسلة: تحليل الرحلة الحالية، تطبيق معايير حديثة، ثم الاختبار قبل الإطلاق.
كيف تحلل رحلة المستخدم الحالية؟
تحليل رحلة المستخدم يعني تتبع كل خطوة يقوم بها العميل داخل تطبيقك من الفتح حتى إتمام الهدف. أدوات مثل Firebase Analytics أو Hotjar تكشف نقاط التسرب — الشاشات التي يغادرها المستخدمون. تشير دراسات معهد Baymard المتخصصة في أبحاث تجربة الاستخدام إلى أن جزءاً كبيراً من التخلي عن العمليات يعود إلى تعقيد الواجهة وكثرة الخطوات؛ ويمكن الاطلاع على أبحاث المعهد المنشورة عبر موقعه الرسمي baymard.com/research للتحقق من الأرقام المحدّثة ومنهجيتها بدلاً من الاعتماد على نسبة مفردة خارج سياقها.
- ارسم خريطة الرحلة الحالية لكل مهمة رئيسية (تسجيل الدخول، الشراء، الدفع).
- حدد الشاشات ذات أعلى معدل ارتداد باستخدام بيانات التحليلات.
- اجمع تقييمات App Store السلبية لتحديد الشكاوى المتكررة.
لماذا تطبيق معايير التصميم الحديثة ضروري؟
معايير التصميم الحديثة تضمن أن تطبيقك يبدو مألوفاً ويعمل بسلاسة على أحدث أجهزة iPhone. Apple تُحدّث إرشادات Human Interface Guidelines دورياً، ومع الإصدارات الأخيرة أصبح دعم عناصر مثل Dynamic Island والوضع الداكن (Dark Mode) ومكونات SwiftUI معياراً متوقعاً. التطبيقات التي تلتزم بهذه المعايير تحصل عادةً على قبول أفضل من المستخدمين، ويمكن مراجعة التفاصيل الرسمية عبر Human Interface Guidelines.
- اعتماد نظام تصميم موحد (Design System) للألوان والخطوط والأزرار.
- تبسيط التنقل إلى ثلاث نقرات أو أقل للوصول لأي وظيفة أساسية.
- ضمان الاستجابة لأحجام الشاشات المختلفة من iPhone SE حتى Pro Max.
- دعم اللغة العربية والاتجاه من اليمين لليسار (RTL) بشكل كامل عبر Semantic Content Attribute، وهو جانب يُهمَل كثيراً في التطبيقات القديمة الموجهة للسوق العربي.
كيف تختبر التصميم الجديد مع المستخدمين؟
الاختبار مع المستخدمين الحقيقيين يمنع إطلاق تصميم يبدو جميلاً لكنه غير عملي. تشير أبحاث Nielsen Norman Group الشهيرة في مجال قابلية الاستخدام إلى أن اختباراً مع عدد صغير من المستخدمين (نحو خمسة) يكشف نسبة كبيرة من مشكلات الواجهة الرئيسية؛ ويمكن الاطلاع على منهجيتهم عبر موقعهم الرسمي nngroup.com. في السوق المصري والخليجي، من الأفضل اختبار نماذج أولية مع عينة من العملاء الفعليين قبل بدء البرمجة، لأن تكلفة تعديل نموذج أولي (Prototype) أقل بكثير من تعديل كود مكتمل.
من الممارسات المتبعة بناء نموذج تفاعلي في Figma وإجراء جلسات اختبار مع مستخدمين من الجمهور المستهدف، ثم تعديل التصميم بناءً على ملاحظاتهم قبل تسليمه لفريق التطوير — ما يوفر تكاليف إعادة العمل بعد الإطلاق.
تكلفة إعادة تصميم تطبيق iOS في مصر والخليج 2026
إعادة تصميم تطبيقات iOS القديمة يلعب دوراً محورياً في هذا السياق.
تتراوح تكلفة إعادة تصميم تطبيق iOS قديم في 2026 تقديرياً بين 80,000 و400,000 جنيه مصري (ما يعادل تقريباً 6,500 إلى 33,000 ريال سعودي)، حسب حجم التطبيق ومدى تعقيد وظائفه ودرجة الديون التقنية المتراكمة في الكود القديم.
منهجية التسعير وكيف نصل إلى هذه النطاقات
لأن أسعار السوق تتغير ولا تصدر عن جهة تسعير مركزية، تُبنى النطاقات أدناه على منهجية تقدير شائعة بين الفرق التقنية: تقدير عدد ساعات العمل لكل مرحلة (تحليل، تصميم، برمجة، اختبار) مضروباً في متوسط الأجرة بالساعة في كل سوق. هذه أرقام استرشادية للتخطيط لا أسعار نهائية؛ ويُنصح بطلب عرض سعر تفصيلي بعد تدقيق تقني للكود الفعلي. يوضح الجدول التالي متوسطات تقديرية في السوق المصري والخليجي لعام 2026:
| نوع المشروع | السعر بالجنيه المصري (تقديري) | السعر بالريال السعودي (تقديري) |
|---|---|---|
| تحديث UX/UI بسيط | 80,000 – 150,000 | 6,500 – 12,000 |
| ترقية تدريجية للكود (Swift) | 150,000 – 280,000 | 12,000 – 23,000 |
| إعادة كتابة كاملة | 280,000 – 400,000+ | 23,000 – 33,000+ |
العوامل المؤثرة في التكلفة
عوامل عدة تدفع السعر لأعلى أو لأسفل، ويجب على صاحب المشروع تقييمها قبل طلب عرض سعر:
- عدد الشاشات والوظائف داخل التطبيق (تطبيق تجارة إلكترونية أعقد من تطبيق محتوى بسيط).
- حجم الكود القديم بلغة Objective-C ونسبة الأجزاء القابلة لإعادة الاستخدام.
- تكامل التطبيق مع أنظمة خارجية مثل بوابات الدفع أو أنظمة CRM.
- خبرة الفريق المنفذ؛ إذ تميل الأجرة بالساعة للمطور المحترف في الخليج إلى تجاوز نظيرتها في مصر.
العائد على الاستثمار
العائد على إعادة التصميم يظهر عادةً خلال 6 إلى 12 شهراً في كثير من الحالات، لكن هذا يتوقف على حجم التطبيق وطبيعة نشاطه. الآليات التي يتحقق عبرها العائد ملموسة: تحسين معدل الاحتفاظ يقلل تكلفة اكتساب مستخدمين جدد، وتقليص الديون التقنية يخفض ساعات الصيانة الشهرية، وتحسين تجربة الدفع يرفع معدل إتمام العمليات. أي نسبة زيادة يجب قياسها فعلياً عبر أدوات التحليلات قبل وبعد الإطلاق، لا افتراضها مسبقاً.
لتقدير العائد بموضوعية، ابنِ نموذجاً بسيطاً: خذ معدل التحويل الحالي، وقدّر التحسن المتوقع بشكل متحفظ، واحسب أثره على الإيراد الشهري، ثم اقسم تكلفة إعادة التصميم على الزيادة الشهرية المتوقعة لتحصل على فترة الاسترداد التقديرية. من الممارسات الجيدة ربط ميزانية التحديث بمؤشرات أداء قابلة للقياس (KPIs) قبل بدء المشروع لضمان قرار استثماري مدروس، مع تعديل التقديرات بمجرد توفر بيانات حقيقية بعد الإطلاق.
كيف تختار شريكاً لإعادة تصميم تطبيقك
اختيار شريك تقني لإعادة تصميم تطبيق iOS قديم يعتمد على ثلاثة معايير أساسية: خبرة موثقة في التعامل مع الكود القديم مثل Objective-C، معرض أعمال يضم مشاريع تحديث فعلية، ومنهجية واضحة لنقل البيانات دون فقدانها. الشركة المناسبة لا تعدك بإعادة كتابة سريعة، بل تبدأ بتدقيق تقني للكود الحالي.
معايير تقييم الشركة قبل التوقيع
تقييم الشركة يبدأ بطلب أمثلة على مشاريع سابقة أعادت فيها بناء تطبيقات قائمة، وليس تطبيقات جديدة فقط. الفرق جوهري: بناء تطبيق من الصفر أسهل بكثير من ترقية كود عمره ست سنوات مع الحفاظ على مستخدميه الحاليين. اسأل عن نسبة المشاريع التي سُلّمت في الموعد المحدد — الشركات الجادة تشارك هذا الرقم بشفافية.
- الخبرة في Swift وSwiftUI: تأكد أن الفريق يتقن أحدث أطر Apple، لا مجرد صيانة كود قديم.
- عملية اختبار موثقة: اطلب خطة اختبار تشمل الأجهزة القديمة والحديثة قبل الإطلاق، مع تغطية آلية (Automated Testing) للوظائف الحرجة.
- نموذج تسعير واضح: احذر الأسعار المنخفضة جداً، فهي غالباً تعني تجاهل الدين التقني الذي سيظهر لاحقاً. اطلب تفصيلاً للساعات لكل مرحلة.
- دعم ما بعد الإطلاق: اتفاق صيانة لمدة لا تقل عن ستة أشهر يقلل مخاطر الأعطال المبكرة.
لماذا الخبرة في التطبيقات القديمة حاسمة
الخبرة في التطبيقات القديمة تؤثر بقوة في نجاح المشروع بأكمله، لأن جزءاً كبيراً من مخاطر إعادة التصميم ينبع من التعامل مع الكود المتراكم والاعتماديات القديمة (Legacy Dependencies)، لا من التصميم البصري وحده. فريق واجه مشاكل ترحيل بيانات حقيقية يعرف أين تختبئ الأخطاء — في مخططات قواعد البيانات القديمة، وتنسيقات التخزين المهجورة، والتوافق العكسي (Backward Compatibility) — بينما فريق بلا هذه الخبرة يكتشفها متأخراً بعد استنزاف الميزانية.
الخلاصة القابلة للتطبيق: اختر شريكاً يبدأ بتدقيق كودك الحالي قبل أن يقتبس السعر، لأن من يقدّم عرضاً دون فحص لا يفهم حجم العمل الفعلي.
إن رغبت في تدقيق تقني لتطبيقك القديم قبل اتخاذ القرار، يمكنك التواصل مع فريق أغربـة.
المصادر والمراجع
- Apple — Human Interface Guidelines (المرجع الرسمي لمعايير تصميم واجهات iOS).
- Apple — App Store Review Guidelines (متطلبات مراجعة ورفع التطبيقات).
- Apple — SwiftUI Documentation (الوثائق الرسمية لإطار SwiftUI).
- Apple — Security Documentation (متطلبات وواجهات الأمان).
- Baymard Institute — أبحاث تجربة الاستخدام والتخلي عن العمليات.
- Nielsen Norman Group — عدد المستخدمين اللازم لاختبار قابلية الاستخدام.
ملاحظة حول التحديث والشفافية: نُشر هذا الدليل في يناير 2026 ويستند إلى الوثائق الرسمية من Apple والأبحاث المشار إليها أعلاه. متطلبات App Store وإصدارات SDK تتغير سنوياً، لذا يُوصى بالرجوع إلى المصادر الرسمية للتحقق من الأرقام والمواعيد قبل اتخاذ أي قرار تنفيذي.