لماذا لا يحصل Windows على تطبيقات أصلية مثل MacOS?

يناقش هذا المقال الملخص والمترجم من Windows Latest أسباب عدم تطوير تطبيقات أصلية لنظام التشغيل Windows.
لماذا يستمر Windows 11 في الحصول على تطبيقات ويب بدلًا من التطبيقات الأصلية Native?
انتقل تطوير تطبيقات Windows من نموذج واحد مستقر إلى عدة أُطر عمل، مما دفع المطورين نحو تطبيقات الويب.
عندما اتخذ WhatsApp القرار الذي كرهه الجميع بالتحول من تطبيق Windows أصلي (Native) إلى غلاف ويب (web wrapper)، كان معظم النقد موجّهًا إلى Meta. وهذا منطقي. بدا الأمر كسلاً، وكان تراجعًا واضحًا يستهلك الذاكرة (RAM) بشكل أكبر، كما أزال ما تبقى من تجربة “أصلية” على Windows.
لكن الواقع أكثر تعقيدًا.

حتى Meta لم يكن لديها دافع كبير للاستمرار في تطوير تطبيق Windows الأصلي. الشركة بالكاد قامت بتحديثه، ولم توفّر تكافؤًا في الميزات، وفي النهاية اعتمدت النسخة المبنية على الويب. السبب الرئيسي على الأرجح هو أن تطبيقات الويب أرخص في البناء والصيانة. لكن المشكلة الحقيقية هي أن Microsoft لم تقدّم للمطورين إطار واجهة مستخدم (UI framework) يمكن الاعتماد عليه على المدى الطويل. بينما تطبيقات الويب لا تعاني من هذه المشكلة.
استمعنا مؤخرًا إلى رأي قارئ قديم لموقع Windows Latest، وهو أيضًا مطوّر يُدعى Alexander Ovchinnikov، وقد عبّر عن نقاط تعكس ما يشعر به الكثير من المطورين.
على عكس macOS، الذي يحصل دائمًا على تطبيقات أصلية رغم قاعدة مستخدمين أصغر، فإن توجه المطورين نحو تطبيقات الويب في Windows لا يتعلق بالراحة، بل بالثقة، أو بالأحرى غيابها.
على مر السنوات، قدمت Microsoft عدة أُطر عمل باعتبارها “المستقبل”، ثم تخلت عنها لاحقًا. من WPF وSilverlight إلى UWP والآن WinUI 3، لم يتغير هذا النمط. وكما قال Alexander، أصبح العديد من المطورين يفترضون أن ما تروّج له Microsoft اليوم قد لا يستمر طويلًا بما يكفي لبناء مشاريع عليه.
لم تمتلك Microsoft استراتيجية واضحة لواجهات المستخدم (GUI) منذ عقود، وأصبح Windows اليوم يقدم عددًا كبيرًا من الأُطر دون إجابة واضحة حول ما يجب على المطورين استخدامه فعليًا.
هذا يغيّر النظرة إلى تطبيقات الويب على Windows. فهي ليست الخيار المثالي، بل خيار احتياطي عندما تبدو المنصة نفسها غير مستقرة. ومع ذلك، قد تؤدي محاولات Microsoft الأخيرة للتركيز على التطبيقات الأصلية 100% إلى تغيير هذا الوضع.

من مسار تطوير واضح إلى فوضى من الخيارات:

كان هناك وقت لم يكن فيه تطوير تطبيقات Windows يتطلب تفكيرًا معقدًا. في البداية، كان هناك نهج واحد واضح: Win32. واجهة برمجية واحدة (API)، ونموذج ذهني بسيط، وطريقة واضحة لإنجاز العمل.
كتاب “Programming Windows” لـ Charles Petzold، والذي كان يُعتبر “الإنجيل” لمطوري Windows، جعل هذا المجال سهل الفهم. وكان المطورون يستثمرون وقتهم بثقة، لأن المنصة كانت مستقرة. هذه الثقة ساهمت في نمو النظام البيئي.
لكن بدلًا من تطوير Win32 ليصبح أكثر حداثة، استمرت Microsoft في تقديم طبقات جديدة وبدائل. بدأ الأمر مع MFC كغلاف لـ C++، ثم WinForms لمطوري .NET، ثم WPF مع XAML وتسريع العتاد، ثم Silverlight كخيار متعدد المنصات، وبعدها WinRT وUWP في عصر Windows 8 وWindows 10، والآن لدينا WinUI 3 مع Windows App SDK، بالإضافة إلى MAUI للتطوير متعدد المنصات.
كل واحدة من هذه التقنيات قُدّمت على أنها “مستقبل تطوير Windows”، وكل منها طلب من المطورين استثمار وقتهم وتعلم أنماط جديدة.
المشكلة لم تكن في جودة هذه التقنيات، فالكثير منها كان متقدمًا على عصره. المشكلة أن “المستقبل” كان يتغير قبل أن يستقر. وبدلًا من منصة واحدة تتطور، وجد المطورون أنفسهم يلاحقون أهدافًا متحركة.
أشار Jeffrey Snover في مدونة تفصيلية إلى أن Windows لم يعد يملك إجابة واضحة لسؤال بسيط: كيف يجب بناء تطبيق Windows؟
كان من المفترض أن يكون WPF هو المستقبل، ثم جاء Silverlight، ثم تحولت Microsoft إلى HTML5. وتم الترويج لـ UWP كمنصة موحدة، لكنها لم تحقق انتشارًا واسعًا حتى داخل Microsoft نفسها. أما WinUI 3، فهو الحل الحديث حاليًا، لكنه لم يمنح المطورين نفس مستوى الثقة الذي كان موجودًا سابقًا.
مع كل إطار جديد، يبدأ المطورون في اعتماده، ثم تتغير الاستراتيجية، ويتحول الاهتمام إلى شيء آخر. لا يتم إلغاء الإطار القديم دائمًا، لكنه يفقد أهميته تدريجيًا. تكررت هذه الدورة مرات كافية لدرجة أن المطورين توقفوا عن الالتزام الكامل.
وكما قال Alexander: إذا لم تستطع Microsoft الالتزام بالأُطر السابقة، فلماذا نفترض أن الحالي سيكون مختلفًا؟
اليوم، إذا سألت مطورًا ماذا يجب أن يستخدم لبناء تطبيق Windows، فالإجابة تعتمد على من تسأل. البعض لا يزال يوصي بـ Win32، وآخرون يفضلون WPF لاستقراره، وWinUI 3 يُعتبر حديثًا لكنه غير موثوق بالكامل بعد، وMAUI للتطبيقات متعددة المنصات، وهناك أيضًا خيار الويب باستخدام Electron أو PWAs، إضافة إلى أُطر خارجية مثل Avalonia وQt.
هذا ليس تنوعًا صحيًا في الخيارات، بل حالة من عدم اليقين الكامل.

لماذا يختار المطورون تطبيقات الويب بدلًا من التطبيقات الأصلية:

العديد من أشهر تطبيقات Windows ليست أصلية فعليًا. مثل WhatsApp وSpotify وDiscord وSlack وNotion وZoom، وحتى بعض تطبيقات Microsoft نفسها مثل Microsoft Teams (قبل إعادة كتابته) وClipchamp تستخدم WebView2.
أصبح من السهل جدًا بناء تطبيق ويب واحد وتشغيله في كل مكان: Windows وmacOS وLinux وحتى داخل المتصفح، دون الحاجة إلى قواعد كود منفصلة. أدوات مثل Electron وChromium-based WebView وProgressive Web Apps جعلت التوزيع أسهل، والتحديثات أسرع، والتكلفة أقل، وهو ما يصعب على الشركات تجاهله.
تحول Microsoft نحو WebView2 يعني تضمين محرك Edge (Chromium) داخل التطبيقات. وهذا يحقق التوافق، لكنه يجعل الكثير من “تطبيقات سطح المكتب” مجرد صفحات ويب داخل حاوية.
لكن العيب واضح: هذه التطبيقات تستهلك RAM أكثر، وتكون أقل استجابة، ولا تتكامل بشكل عميق مع نظام التشغيل. تشغيل عدة تطبيقات Electron في نفس الوقت يمكن أن يستهلك موارد الجهاز بسرعة، وهو أمر كانت التطبيقات الأصلية تتعامل معه بشكل أفضل.
في macOS وiOS، لا يزال المطورون يفضلون التطبيقات الأصلية. حتى الشركات التي تستخدم تقنيات الويب في أماكن أخرى، تبني تطبيقات أصلية لأجهزة Apple. السبب هو أن Apple حافظت على مسار تطوير واضح، باستخدام أُطر مثل Cocoa وAppKit وSwiftUI، والتي يتم دعمها وتطويرها باستمرار.
أما Windows، فلا يملك هذا الوضوح، ولذلك يتصرف المطورون بناءً على ذلك.
بدلًا من المخاطرة بإطار قد يتغير اتجاهه لاحقًا، يختار الكثيرون الويب. ليس لأنه الأفضل، بل لأنه الخيار الأكثر أمانًا.

Microsoft تحاول الإصلاح… لكن ربما متأخرًا

هناك إشارات إلى أن Microsoft تدرك المشكلة. فهناك جهود حديثة لتحسين الأداء، وتقليل الاعتماد على مكونات الويب، وبناء المزيد من التطبيقات الأصلية. كما لاقى تصريح Rudy Huyn الذي يدعو المطورين لبناء تطبيقات أصلية 100% تفاعلًا إيجابيًا.
لكن إصلاح التطبيقات وحده لا يكفي.
حتى لو قدمت Microsoft تطبيقات أفضل، سيبقى المطورون مترددين. هذا التردد لا يتعلق بقدرات WinUI 3 اليوم، بل بما حدث في الماضي. سنوات من تغيير الاتجاهات جعلت المطورين حذرين، وهذا لا يتغير بسرعة.
إذا أرادت Microsoft تغيير ذلك، فعليها الالتزام الكامل بإطار واحد، والتواصل بوضوح مع المطورين، ودعمه لفترة كافية لينضج، مع توفير مسارات انتقال واضحة عند التغييرات.

المشكلة الحقيقية ليست التقنية، بل الاستمرارية:

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

تطبيقات الويب ليست المشكلة، بل نتيجة لها

تطبيقات الويب لا تسيطر على Windows لأنها الأفضل للحواسيب المكتبية، ففي كثير من الحالات هي أسوأ. لكنها تنتشر لأنها توفر الاستقرار للمطورين الذين لم يعودوا يرغبون في المخاطرة بالاعتماد على منصة غير مستقرة.
لا يمكن لوم المطورين على اتخاذ قرار محسوب بناءً على التجارب السابقة.
إذا أرادت Microsoft تحسين جودة التطبيقات على Windows، فالحل ليس فقط في إصلاح Windows 11 أو بناء تطبيقات أصلية، بل في إعادة بناء الثقة مع المطورين، وإثبات أن هذه المرة، المنصة — وربما WinUI 3 — ستبقى مستقرة.
المصدر.