HarborDB
العودة إلى المدونة
macOS
Swift
تطوير
الأداء

تطوير تطبيقات Mac الأصلية: لماذا لا يكفي Electron دائمًا

3 نوفمبر 2025
فريق HarborDB

في HarborDB، اتخذنا قرارًا مثيرًا للجدل في وقت مبكر: قمنا ببناء تطبيق macOS أصلي باستخدام Swift و SwiftUI، بدلاً من استخدام إطار عمل متعدد المنصات مثل Electron (المستخدم بواسطة VS Code، و Slack (الثقيل)، و Discord، وما إلى ذلك) أو Tauri.

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

حجة الأداء: الذاكرة والمؤشرات (Threads)

عبء Electron

يقوم كل تطبيق Electron بتجميع نسخة كاملة من Chromium و Node.js.

  • استخدام ذاكرة الوصول العشوائي (RAM) في وضع الخمول: ~ 150 ميجابايت لنافذة "Hello World".
  • استخدام RAM الفعلي: غالبًا ما يستخدم Slack أكثر من 1 جيجابايت لمجرد عرض النص.
  • البنية: كل نافذة هي عملية عرض منفصلة. يتطلب الاتصال بين العملية الرئيسية (Node) والعرض (UI) تسلسلًا (IPC)، وهو بطيء لأحجام البيانات الكبيرة.

الميزة الأصلية

يشارك تطبيق SwiftUI مكتبات نظام التشغيل التي تم تحميلها بالفعل في الذاكرة.

  • استخدام RAM في وضع الخمول: ~ 15-30 ميجابايت.
  • التعامل مع البيانات: يمكننا تمرير مؤشرات الذاكرة مباشرة من محرك قاعدة البيانات (C++) إلى طبقة واجهة المستخدم (Swift) دون نسخ البيانات (Zero-Copy).

مثال ملموس: تحميل 100,000 صف في جدول.

  • Electron: يجب تسلسل كائن JS -> IPC -> إلغاء التسلسل في العارض -> إنشاء DOM. (تأخير ملحوظ).
  • Swift: تحميل الهياكل في الذاكرة -> NSTableView أو List يتم تمريرها فورًا وعرض ما هو مرئي فقط.

تكامل النظام العميق

كونك "تطبيق Mac مناسب" يعني أكثر من مجرد وجود شريط القائمة في الأعلى. يعني دعم الميزات التي يدفع مستخدمو Mac ثمنها.

1. اختصارات لوحة المفاتيح والتركيز

غالبًا ما تتعامل تطبيقات الويب مع تركيز لوحة المفاتيح المعقد بشكل سيء. هل حاولت يومًا الخروج من محرر التعليمات البرمجية في تطبيق ويب باستخدام Tab؟ نظام المستجيب الأصلي لنظام التشغيل macOS (NSResponder) يتعامل مع انتشار الأحداث بشكل متوقع وقياسي.

2. نظام الملفات

HarborDB هي أداة قاعدة بيانات. تحتاج لقراءة ملفات SQLite ومقالب SQL الضخمة وتصديرات CSV. يتم وضع المتصفحات (وبالتالي Electron) في "وضع الحماية" (sandboxed) بقوة لأسباب أمنية. على الرغم من أن Electron يمكنه الوصول إلى نظام الملفات، إلا أن التجربة ليست سلسة أبدًا مثل إطار العمل الأصلي FileCoordinator، الذي يتعامل مع:

  • قفل الملفات.
  • التحديثات الذرية.
  • التنسيق مع iCloud Drive.

3. الخدمات و Automator

يكشف التطبيق الأصلي عن "الخدمات". يمكنك النقر بزر الماوس الأيمن فوق ملف .db في Finder ورؤية إجراء مخصص. يمكنك كتابة نصوص للتطبيق عبر AppleScript أو الاختصارات (Shortcuts).

"البرمجيات الأصلية تحترم كمبيوتر المستخدم. لا تتظاهر بأنها البرنامج الوحيد قيد التشغيل."

تجربة المطور (DX): Swift مقابل Typescript

هذا هو المكان الذي تصبح فيه الأمور ذاتية، ولكن اسمعنا.

TypeScript مذهلة. إنها أفضل أداة لبناء واجهات مستخدم الويب. لكن نظام JavaScript البيئي هش. هناك 10,000 تبعية في node_modules، وتكوينات webpack/vite/rollup معقدة، وتغييرات مستمرة.

Swift مكتوبة بقوة، ومترجمة، وسريعة بجنون. مع SwiftUI، يكون بناء واجهات تعريفية بنفس سرعة React، ولكن مع:

  • أمان حقيقي للنوع في وقت الترجمة (لا يوجد any).
  • ارتباطات مباشرة بـ C++ APIs (عبر Objective-C++ أو Swift C Interop).
  • أدوات توصيف مذهلة (Xcode Instruments) توضح لك بدقة أي سطر من التعليمات البرمجية يخصص الذاكرة أو يحظر الخيط الرئيسي.

لماذا لا يستخدم الجميع Native؟

إذا كان Native رائعًا جدًا، فلماذا يفوز Electron؟

  1. متعدد المنصات: هذا هو السبب الواضح.
  2. التوظيف: يوجد 100 مطور React لكل مطور Swift/macOS واحد.
  3. سرعة التكرار: دفع تحديث الويب فوري؛ يتطلب دفع تحديث تطبيق أصلي مراجعة متجر التطبيقات أو تحديثات Sparkle.

رهاننا

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

HarborDB سريع. يفتح في 200 مللي ثانية. يقوم بتمرير مليون صف بسرعة 120 إطارًا في الثانية. يحترم اختصارات لوحة المفاتيح الخاصة بك.

قد تكون مدرسة قديمة، لكن بالنسبة لنا، إنها مستقبل الإنتاجية المهنية.