تطبيقات iOS أصلية تبدو جزءاً من الجهاز
يشمل تطوير iOS الأصلي تطبيقات iPhone وiPad المكتوبة بلغة Swift، ومعها الأدوات المصغّرة (Widgets) وApp Clips والتطبيقات المرافقة على Apple Watch، وما يحيط بها من عمل على App Store. وهو الخيار الصحيح حين يكون جمهورك في معظمه على أجهزة Apple، أو حين يعتمد المنتج على HealthKit أو ARKit أو Apple Pay أو المعالجة في الخلفية أو جودة حركة لا توفرها أطر العمل متعددة المنصات بالقدر نفسه.
نتبع إرشادات Apple لتصميم الواجهات (Human Interface Guidelines) ونبني بإطار SwiftUI أولاً، ونلجأ إلى UIKit حين تحتاج شاشة إلى تحكم أدق. ويدخل Dynamic Type وVoiceOver والوضع الداكن في البناء الأول، لأن إضافتها لاحقاً أعلى تكلفة. وتصل الإصدارات عبر TestFlight إلى مختبرين حقيقيين، ونتولى التوقيع وإقرارات الخصوصية ومراجعة Apple، فلا يحمل التقديم مفاجآت في النهاية.
واجهات SwiftUI
شاشات مبنية بإطار SwiftUI، ومعه UIKit عند الحاجة، تدعم Dynamic Type والوضع الداكن وتخطيطات iPad وأنماط التنقل التي يعرفها مستخدمو iPhone.
الربط مع أطر عمل Apple
نربط HealthKit وARKit وCore ML وMapKit وCore Location وCore Bluetooth بمنتجك، مع طلبات أذونات تأتي في وقتها وبصياغة يفهم معها الناس ما يُطلب منهم.
المدفوعات والاشتراكات
Apple Pay للسلع المادية، وStoreKit للمشتريات والاشتراكات داخل التطبيق، مع التحقق من الإيصالات على خادمك ومعالجة التجديد والاسترداد.
العمل دون اتصال والمزامنة
تخزين محلي بـ SwiftData أو Core Data، وتحديث في الخلفية، ومعالجة للتعارضات، فيبقى التطبيق مفيداً داخل نفق، وتتسق بياناته بعد الخروج منه.
الأدوات المصغّرة والإضافات
أدوات مصغّرة على الشاشة الرئيسية وشاشة القفل، وLive Activities، وApp Intents لخدمة Siri وتطبيق الاختصارات، وإضافات للمشاركة تضع منتجك حيث ينظر الناس أصلاً.
التسليم على App Store
نتولى الشهادات وملفات التهيئة وبيانات الخصوصية ومجموعات TestFlight والإطلاق المرحلي والرد على مراجعة Apple، وتصدر النسخ عن مسار آلي.
ما تتسلمه منا
- شيفرة Swift المصدرية في مستودعك
- مشروع Xcode مع مخططات البناء
- صفحة التطبيق على App Store ولقطات الشاشة
- نسخ TestFlight لمختبريك
- مجموعات اختبارات الوحدات والواجهة
- أتمتة الإصدار بأداة Fastlane
- إعداد تقارير الأعطال والتحليلات
- التطبيق منشور عبر حسابك في Apple
طريقة عملنا
- 01
نحدد ونبني نموذجاً أولياً
نتفق على المسارات الأساسية وأطر عمل Apple المعنية وأدنى إصدار من iOS، ثم نبني نموذجاً أولياً لأكثر تفاعل محفوف بالمخاطر على جهاز حقيقي، لنتأكد أنه يعمل كما صُمم.
- 02
نصمم لنظام iOS
نصمم الشاشات وفق إرشادات Apple، آخذين في الحسبان مكونات النظام وDynamic Type والوضع الداكن، ونراجعها في نموذج أولي قابل للنقر قبل أن يبدأ المهندسون العمل عليها.
- 03
نبني ونجرّب عبر TestFlight
تصل الميزات إلى TestFlight في نسخ منتظمة يستطيع فريقك تثبيتها. ونختبر على مقاسات مختلفة من iPhone وiPad وإصدارات مختلفة من iOS، ونتابع الأعطال وملاحظات المختبرين.
- 04
نقدّم ونطلق
نجهّز صفحة التطبيق وبيانات الخصوصية وملاحظات المراجعة، ونقدّم التطبيق لمراجعة Apple ونجيب عن أي أسئلة. ثم يُطرح الإصدار على مراحل بينما نراقب بيانات الأعطال والأداء.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| اللغة | Swift، SwiftUI، UIKit، Combine |
| أطر العمل | HealthKit، ARKit، Core ML، StoreKit، WidgetKit |
| البيانات | SwiftData، Core Data، CloudKit، Firebase |
| الأدوات | Xcode، TestFlight، Fastlane، XCTest |
منتجك يعتمد على ما لا يقدّمه إلا iOS
يحمل معظم مستخدميك iPhone، والتجربة التي تتصورها تعتمد على أجهزة Apple أو ميزات نظامها، مثل البيانات الصحية والواقع المعزز والأدوات المصغّرة والدفع عبر المحفظة. وتريد تطبيقاً يبدو أصلياً ويواكب كل إصدار جديد من iOS.
- تطبيقات الصحة واللياقة
- مسارات الدفع عبر Apple Pay
- أدوات iPad للفرق الميدانية
- معاينة المنتجات بالواقع المعزز
- تطبيقات الاشتراكات عبر StoreKit
- إعادة بناء تطبيق قديم مكتوب بلغة Objective-C
أسئلة شائعة
متى نختار iOS الأصلي بدل React Native؟
اختر التطوير الأصلي حين يعتمد التطبيق بقوة على أطر عمل Apple مثل HealthKit أو ARKit أو Core Bluetooth، أو يحتاج إلى الأدوات المصغّرة أو Live Activities أو تطبيق مرافق على Apple Watch، أو حين تكون جودة الحركة والتمرير في صميم المنتج. واختر React Native حين تحتاج إلى iOS وAndroid معاً، وشاشاتك في معظمها نماذج وقوائم ومحتوى، وسيصون فريق واحد النسختين. نبني الاثنين، وسنقول لك أيهما يناسبك.
هل تبنون بإطار SwiftUI أم UIKit؟
SwiftUI خيارنا الافتراضي للتطبيقات الجديدة، لأن Apple تستثمر فيه، ولأنه يحتاج إلى شيفرة أقل في الشاشات القياسية. ويبقى UIKit الأداة الأفضل في بعض الحالات، منها تخطيطات المجموعات المعقدة، وتحرير النصوص المخصص، وبعض تفاعلات الكاميرا أو الخرائط، ويعمل الاثنان معاً في التطبيق نفسه. وفي شيفرة UIKit القائمة نضيف SwiftUI شاشة بعد شاشة، بدل إعادة كتابة ما يعمل.
كيف تتعاملون مع مراجعة App Store وحالات الرفض؟
نقلل الخطر مبكراً بفحص فكرتك مقابل إرشادات مراجعة App Store أثناء تحديد النطاق، ولا سيما في المدفوعات، وحذف الحساب، وإفصاحات الخصوصية، والمحتوى الذي ينشئه المستخدمون. وقبل التقديم نستكمل بيانات الخصوصية وملاحظات المراجعة وحساباً تجريبياً. وإن أثارت Apple مشكلة، نرد عليها ونجري التعديل ونعيد التقديم. والموافقة قرار Apple، لذلك لا نستطيع أن نعد بنتيجة أو موعد.
ما إصدارات iOS والأجهزة التي سيدعمها التطبيق؟
نحسم ذلك أثناء تحديد النطاق، مستندين إلى بيانات جمهورك إن وُجدت. فدعم إصدار iOS الحالي والذي قبله يغطي معظم الأجهزة النشطة، ويُبقي الواجهات البرمجية الأحدث متاحة، أما الرجوع أبعد من ذلك فيزيد جهد الاختبار ويحدّ مما يستطيعه SwiftUI. ودعم iPad قرار مستقل، لأن تخطيط iPad الجيد يُصمم للشاشة الأكبر، ولا يكون أبداً تطبيق هاتف ممطوطاً.
ماذا يحدث بعد نشر التطبيق على App Store؟
يحتاج تطبيق iOS إلى عناية كل عام، لأن كل إصدار جديد من iOS وكل جهاز جديد قد يغيّر سلوكه، ولأن Apple تحدّث متطلباتها. بعد الإطلاق نراقب الأعطال والمراجعات، ونصلح المشكلات، ونخطط للإصدار التالي معك. ويمكن أن يغطي العمل المستمر ترتيب دعم يحدده عرض مكتوب. وإن تولى فريقك الأمر، فإنه يتسلم الشيفرة المصدرية كاملة والتوثيق ومسار الإصدار.