ربط تطبيقات Swift بقاعدة بيانات Firebase

عندما تبدأ في بناء تطبيق iOS باستخدام Swift، ستكتشف بسرعة أن التطبيق الجميل وحده لا يكفي. المستخدم يريد تسجيل دخول، حفظ بياناته، مزامنة المحتوى بين أجهزته، واسترجاع المعلومات بسرعة وبشكل آمن. هنا تظهر قوة Firebase، لأنها تمنحك بنية جاهزة وقابلة للتوسع من دون أن تضطر إلى بناء خادم كامل من الصفر. وفي عالم Swift، هذا يعني أنك تستطيع الانتقال من فكرة إلى تطبيق يعمل فعلاً في وقت أقل، مع تحكم جيد في البيانات وتجربة مستخدم سلسة.

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

الجميل في Firebase أنه لا يطلب منك أن تكون خبيراً في السيرفرات حتى تبدأ. تستطيع أن تبني تطبيقاً بسيطاً اليوم، ثم توسع بنيته تدريجياً مع نمو المشروع. ومع ذلك، النجاح هنا لا يعتمد فقط على كتابة أكواد تعمل، بل على كتابة أكواد منظمة، آمنة، وسهلة الصيانة. لهذا سأقدم الشرح بطريقة عملية، مع أمثلة واضحة، وكأننا نبني المشروع معاً خطوة بخطوة.

لماذا Firebase مع Swift؟

عند مقارنة Firebase مع بناء Backend تقليدي، نجد أن Firebase يختصر عليك الكثير من الوقت. فبدلاً من إنشاء API منفصلة، وقاعدة بيانات، ونظام مصادقة، ولوحة إدارة، يمكنك الحصول على أغلب هذه المكونات جاهزة. هذا لا يعني أنه مناسب لكل المشاريع، لكنه خيار ممتاز للتطبيقات التي تحتاج سرعة في التطوير، مزامنة لحظية، وتكلفة بداية منخفضة.

من وجهة نظر مطور Swift، Firebase مريح للغاية لأنه يتكامل بسلاسة مع iOS. المكتبة الرسمية واضحة، والتوثيق غني، والمجتمع كبير. كما أن Firestore يوفر بنية بيانات مرنة تعتمد على الوثائق والمجموعات، وهذا يناسب كثيراً طبيعة تطبيقات الموبايل الحديثة. إذا كنت تبني تطبيقاً لإدارة مهام، متجر إلكتروني، دفتر ملاحظات، نظام حجز، أو حتى تطبيق اجتماعي بسيط، فإن Firebase غالباً سيكون خياراً عملياً جداً.

لكن هناك نقطة مهمة: السهولة لا تعني تجاهل البنية الجيدة. كثير من المطورين يبدأون بسرعة ثم تتعقد الشفرة لاحقاً لأنهم يضعون كل شيء في ViewController واحد أو داخل ملف SwiftUI واحد. لذلك، ونحن نربط Swift بFirebase، سنحرص أيضاً على التنظيم: نماذج بيانات، طبقة خدمات، واستدعاءات واضحة ومفهومة.

ما الذي سنستخدمه تحديداً؟

في هذا المقال سنركز على العناصر التالية:

Firestore كقاعدة بيانات رئيسية لأنها حديثة ومرنة وتدعم الاستماع الفوري للتحديثات.

Firebase Authentication لتسجيل الدخول، حتى لو كان مثالنا بسيطاً.

Swift في جانب العميل، سواء باستخدام UIKit أو SwiftUI من حيث المبدأ.

Codable لتحويل البيانات بين Swift وFirestore بشكل نظيف.

إدارة الأخطاء، ومراقبة النتائج، ومعالجة الحالات التي يفشل فيها الاتصال أو تنقص فيها الصلاحيات.

إنشاء مشروع Firebase

أول خطوة هي إنشاء مشروع داخل Firebase Console. بعد تسجيل الدخول بحساب Google، تنشئ مشروعاً جديداً، ثم تضيف تطبيق iOS إليه. أثناء الإضافة ستحتاج عادة إلى إدخال Bundle Identifier الخاص بتطبيقك، وهو أمر مهم جداً لأن Firebase يعتمد عليه لربط التطبيق بالخدمة الصحيحة.

بعد إنشاء التطبيق داخل Firebase، ستقوم بتنزيل ملف GoogleService-Info.plist. هذا الملف يحتوي على إعدادات الربط بين التطبيق ومشروع Firebase. يجب أن تضيفه إلى مشروع Xcode الخاص بك داخل الجذر المناسب للتطبيق، وغالباً داخل Target الصحيح. بدون هذا الملف لن يتم التعرف على التطبيق بشكل سليم.

بعد ذلك تنتقل إلى اختيار طريقة دمج Firebase داخل مشروعك. اليوم أكثر الطرق شيوعاً هي Swift Package Manager، لأنها مدمجة بشكل جيد مع Xcode وتقلل من مشاكل التوافق. ومع ذلك، بعض المشاريع القديمة ما زالت تستخدم CocoaPods، وهو خيار لا يزال يعمل بشكل جيد. في هذا المقال سأذكر الطريقتين، لكن سأعطي الأولوية لـ Swift Package Manager لأنه الأكثر راحة في المشاريع الحديثة.

تثبيت Firebase في Swift باستخدام Swift Package Manager

افتح مشروعك في Xcode، ثم انتقل إلى File > Add Package Dependencies. أضف رابط مستودع Firebase الرسمي، ثم اختر الحزم التي تحتاجها مثل FirebaseFirestore و FirebaseAuth و FirebaseCore.

بعد الإضافة، تأكد من ربط الحزم بالـ Target الصحيح. من الأخطاء الشائعة أن يضيف المطور الحزمة إلى المشروع لكن لا يربطها بالتطبيق، ثم يتفاجأ بأخطاء compile كثيرة.

ثم انتقل إلى ملف بدء التشغيل في التطبيق، مثل AppDelegate إذا كنت تستخدم UIKit، أو إلى مكان التهيئة المناسب في SwiftUI. ستحتاج إلى استدعاء FirebaseApp.configure() حتى يتم تفعيل الاتصال بمشروع Firebase.

مثال UIKit

import UIKit
import FirebaseCore

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        FirebaseApp.configure()
        return true
    }
}

مثال SwiftUI

import SwiftUI
import FirebaseCore

@main
struct MyFirebaseApp: App {
    init() {
        FirebaseApp.configure()
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

هذه الخطوة تبدو بسيطة، لكنها ضرورية للغاية. بدون configure() لن يعمل أي شيء تقريباً من Firebase بالشكل المتوقع.

فهم Firestore قبل البدء

Firestore يعتمد على مفهومين أساسيين: Collections و Documents. يمكنك تخيل Collection كأنها جدول منطقي يحتوي مجموعة عناصر، بينما Document هو سجل مستقل داخل تلك المجموعة. لكن Firestore ليس قاعدة بيانات علائقية تقليدية، لذلك لا يجب أن تفكر فيه تماماً كأنك في MySQL. هنا لا توجد JOINs بالطريقة نفسها، بل تبني البيانات بطريقة تناسب الوصول السريع من التطبيق.

مثلاً، إذا كان لديك تطبيق مهام، يمكنك إنشاء Collection باسم tasks، وكل Task تكون Document تحتوي على حقول مثل العنوان، الوصف، الحالة، وتاريخ الإنشاء. وإذا كنت تبني تطبيقاً للمستخدمين، قد يكون لديك users، ثم لكل مستخدم مستند خاص به. اختيار البنية الصحيحة مهم جداً لأنه يؤثر على الأداء وسهولة التطوير لاحقاً.

إنشاء نموذج بيانات في Swift

قبل كتابة أي استعلامات، من الأفضل أن تنشئ نموذج بيانات يمثل المستند داخل Swift. هذا يجعل الكود أكثر وضوحاً ويقلل الأخطاء. سنفترض أننا نبني تطبيق مهام بسيط.

import Foundation
import FirebaseFirestoreSwift

struct Task: Codable, Identifiable {
    @DocumentID var id: String?
    var title: String
    var details: String
    var isDone: Bool
    var createdAt: Date
}

في هذا المثال استخدمنا Codable لتسهيل التحويل بين Swift وFirestore، واستخدمنا @DocumentID حتى يلتقط Firestore معرف المستند تلقائياً. لاحظ أن createdAt من الأفضل أن يكون Date وليس String، لأن التاريخ الحقيقي أسهل في الفرز والتصفية.

إضافة بيانات إلى Firestore

الآن نصل إلى أول خطوة عملية: إنشاء مستند جديد داخل Firestore. عادة ستستخدم مرجعاً إلى collection، ثم تضيف المستند ببياناته. الأفضل أن تفصل هذا المنطق داخل Service class حتى لا يتكدس داخل الواجهة.

مثال لإضافة Task

import FirebaseFirestore
import FirebaseFirestoreSwift

final class TaskService {
    private let db = Firestore.firestore()

    func addTask(task: Task, completion: @escaping (Result<Void, Error>) -> Void) {
        do {
            _ = try db.collection("tasks").addDocument(from: task) { error in
                if let error = error {
                    completion(.failure(error))
                } else {
                    completion(.success(()))
                }
            }
        } catch {
            completion(.failure(error))
        }
    }
}

هذه الطريقة جميلة لأنها تستفيد من addDocument(from:) الذي يحول الـ Codable object مباشرة إلى Firestore. إذا نجحت العملية، يتم حفظ المستند في collection tasks. وإذا حدث خطأ، نستقبله في completion.

مثال الاستخدام

let service = TaskService()

let newTask = Task(
    title: "تعلم Firestore",
    details: "قراءة وطباعة البيانات وتجربة CRUD",
    isDone: false,
    createdAt: Date()
)

service.addTask(task: newTask) { result in
    switch result {
    case .success:
        print("تمت إضافة المهمة بنجاح")
    case .failure(let error):
        print("حدث خطأ: \(error.localizedDescription)")
    }
}

جلب البيانات من Firestore

قراءة البيانات هي القلب الحقيقي لأي تطبيق يعتمد على قاعدة بيانات. عادة ستحتاج إلى جلب قائمة المهام وعرضها داخل TableView أو داخل قائمة SwiftUI. Firestore يوفر طرقاً متعددة للقراءة، إما مرة واحدة أو بشكل فوري مع التحديثات المباشرة.

جلب البيانات مرة واحدة

func fetchTasks(completion: @escaping (Result<[Task], Error>) -> Void) {
    db.collection("tasks").getDocuments { snapshot, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let documents = snapshot?.documents else {
            completion(.success([]))
            return
        }

        let tasks: [Task] = documents.compactMap { document in
            try? document.data(as: Task.self)
        }

        completion(.success(tasks))
    }
}

هذه الطريقة مناسبة عندما تريد تحميل البيانات مرة واحدة فقط. لكنها ليست أفضل حل إذا كان التطبيق يحتاج إلى تحديثات لحظية فور تغير البيانات.

الاستماع للتحديثات اللحظية

import FirebaseFirestore

func listenToTasks(completion: @escaping (Result<[Task], Error>) -> Void) -> ListenerRegistration {
    return db.collection("tasks").addSnapshotListener { snapshot, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let documents = snapshot?.documents else {
            completion(.success([]))
            return
        }

        let tasks: [Task] = documents.compactMap { document in
            try? document.data(as: Task.self)
        }

        completion(.success(tasks))
    }
}

ميزة هذا الأسلوب أنه يرسل التحديثات تلقائياً عند أي تغيير في المجموعة. هذا ممتاز للتطبيقات التفاعلية التي تريد أن تعكس التغيير فوراً على الشاشة.

تحديث مستند موجود

بعد الإضافة والقراءة، ستحتاج غالباً إلى التعديل. مثلاً المستخدم قد يغيّر عنوان المهمة أو يحددها كمكتملة. التحديث في Firestore يحتاج إلى معرف المستند، ولهذا أهمية id في النموذج.

تحديث باستخدام حقلين أو أكثر

func updateTask(taskID: String, title: String, details: String, isDone: Bool, completion: @escaping (Result<Void, Error>) -> Void) {
    db.collection("tasks").document(taskID).updateData([
        "title": title,
        "details": details,
        "isDone": isDone
    ]) { error in
        if let error = error {
            completion(.failure(error))
        } else {
            completion(.success(()))
        }
    }
}

يمكنك أيضاً استخدام setData مع merge: true في بعض الحالات، خصوصاً عندما تريد تحديث جزء من البيانات بدون حذف الحقول الأخرى.

مثال باستخدام merge

func patchTask(taskID: String, values: [String: Any], completion: @escaping (Result<Void, Error>) -> Void) {
    db.collection("tasks").document(taskID).setData(values, merge: true) { error in
        if let error = error {
            completion(.failure(error))
        } else {
            completion(.success(()))
        }
    }
}

هذا الأسلوب عملي عندما تكون مرونة التحديث مهمة، لكن يجب استخدامه بحذر حتى لا تضيف بيانات غير متوقعة.

حذف البيانات من Firestore

الحذف بسيط جداً، لكنه يحتاج إلى أن يكون مدروساً. لا تنسَ أن الحذف عملية نهائية غالباً، لذلك في واجهة المستخدم من الأفضل أن تطلب تأكيداً من المستخدم قبل تنفيذها.

func deleteTask(taskID: String, completion: @escaping (Result<Void, Error>) -> Void) {
    db.collection("tasks").document(taskID).delete { error in
        if let error = error {
            completion(.failure(error))
        } else {
            completion(.success(()))
        }
    }
}

إذا كانت لديك علاقة بين البيانات، مثلاً task مرتبطة بتعليقات أو سجلات فرعية، فلا تعتمد على حذف المستند الأب فقط. في Firestore، يجب أن تفكر في البيانات المرتبطة بشكل واضح، لأن حذف مستند لا يحذف تلقائياً كل البيانات الفرعية في معظم الحالات.

استخدام Firebase Authentication مع قاعدة البيانات

غالباً لا يكون الهدف من قاعدة البيانات مجرد حفظ بيانات عامة، بل حفظ بيانات لكل مستخدم على حدة. لهذا فإن Firebase Authentication مهم جداً. بعد تسجيل المستخدم، يمكنك ربط البيانات الخاصة به بمعرف UID. بهذا الشكل، تستطيع أن تحمي بيانات كل مستخدم وتعرض له فقط ما يخصه.

تسجيل مستخدم جديد

import FirebaseAuth

func signUp(email: String, password: String, completion: @escaping (Result<User, Error>) -> Void) {
    Auth.auth().createUser(withEmail: email, password: password) { result, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let user = result?.user else {
            return
        }

        completion(.success(user))
    }
}

تسجيل الدخول

func signIn(email: String, password: String, completion: @escaping (Result<User, Error>) -> Void) {
    Auth.auth().signIn(withEmail: email, password: password) { result, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let user = result?.user else {
            return
        }

        completion(.success(user))
    }
}

حفظ بيانات المستخدم داخل Firestore

struct AppUser: Codable, Identifiable {
    @DocumentID var id: String?
    var uid: String
    var name: String
    var email: String
    var createdAt: Date
}

func saveUserProfile(user: AppUser, completion: @escaping (Result<Void, Error>) -> Void) {
    do {
        try Firestore.firestore()
            .collection("users")
            .document(user.uid)
            .setData(from: user) { error in
                if let error = error {
                    completion(.failure(error))
                } else {
                    completion(.success(()))
                }
            }
    } catch {
        completion(.failure(error))
    }
}

هنا نلاحظ فكرة مهمة: غالباً نستخدم uid كمعرف للمستند نفسه، لأن ذلك يسهل الوصول إلى بيانات المستخدم بسرعة ووضوح.

تنظيم طبقة الخدمة بشكل احترافي

من الأخطاء الشائعة وضع كل منطق Firestore داخل ViewController أو داخل View. هذا ينجح في البداية، لكنه يتحول إلى فوضى بسرعة. الأفضل أن تنشئ طبقة خدمة مسؤولة عن Firestore، وطبقة ViewModel أو Presenter مسؤولة عن ربط البيانات بالواجهة.

مثال مبسط لبنية منظمة:

final class TaskRepository {
    private let db = Firestore.firestore()

    func createTask(_ task: Task, completion: @escaping (Result<Void, Error>) -> Void) {
        do {
            _ = try db.collection("tasks").addDocument(from: task) { error in
                if let error = error {
                    completion(.failure(error))
                } else {
                    completion(.success(()))
                }
            }
        } catch {
            completion(.failure(error))
        }
    }

    func fetchTasks(completion: @escaping (Result<[Task], Error>) -> Void) {
        db.collection("tasks").getDocuments { snapshot, error in
            if let error = error {
                completion(.failure(error))
                return
            }

            let tasks = snapshot?.documents.compactMap {
                try? $0.data(as: Task.self)
            } ?? []

            completion(.success(tasks))
        }
    }
}

ثم في ViewModel:

import Foundation

final class TaskViewModel: ObservableObject {
    @Published var tasks: [Task] = []
    @Published var errorMessage: String?

    private let repository = TaskRepository()

    func loadTasks() {
        repository.fetchTasks { [weak self] result in
            DispatchQueue.main.async {
                switch result {
                case .success(let tasks):
                    self?.tasks = tasks
                case .failure(let error):
                    self?.errorMessage = error.localizedDescription
                }
            }
        }
    }
}

هذا الفصل بين المسؤوليات يجعل التطبيق أسهل في الاختبار، وأسهل في التطوير، وأقل عرضة للأخطاء.

العمل مع SwiftUI

إذا كنت تستخدم SwiftUI، فالمبدأ نفسه يبقى، لكن الواجهة تكون أكثر بساطة وانسيابية. تستطيع عرض البيانات القادمة من Firestore داخل List.

import SwiftUI

struct TaskListView: View {
    @StateObject private var viewModel = TaskViewModel()

    var body: some View {
        NavigationView {
            List(viewModel.tasks) { task in
                VStack(alignment: .leading, spacing: 6) {
                    Text(task.title)
                        .font(.headline)
                    Text(task.details)
                        .font(.subheadline)
                    Text(task.isDone ? "مكتملة" : "قيد التنفيذ")
                        .font(.caption)
                }
            }
            .navigationTitle("المهام")
            .onAppear {
                viewModel.loadTasks()
            }
        }
    }
}

هذه الواجهة بسيطة، لكنها توضح كيف يمكن ربط Firestore مباشرة بالتطبيق بطريقة نظيفة. ومع الوقت يمكنك إضافة البحث، التصفية، الترتيب، والتحديث بالسحب.

مثال كامل لفورم إضافة مهمة

في كثير من التطبيقات، لن يكون كافياً مجرد جلب البيانات. تحتاج أيضاً إلى شاشة إدخال. إليك مثالاً عملياً بسيطاً:

import SwiftUI

struct AddTaskView: View {
    @State private var title = ""
    @State private var details = ""
    @State private var message = ""

    private let repository = TaskRepository()

    var body: some View {
        VStack(spacing: 16) {
            TextField("عنوان المهمة", text: $title)
                .textFieldStyle(RoundedBorderTextFieldStyle())

            TextField("تفاصيل المهمة", text: $details)
                .textFieldStyle(RoundedBorderTextFieldStyle())

            Button("حفظ") {
                let task = Task(
                    title: title,
                    details: details,
                    isDone: false,
                    createdAt: Date()
                )

                repository.createTask(task) { result in
                    DispatchQueue.main.async {
                        switch result {
                        case .success:
                            message = "تم الحفظ بنجاح"
                            title = ""
                            details = ""
                        case .failure(let error):
                            message = error.localizedDescription
                        }
                    }
                }
            }

            Text(message)
                .font(.footnote)
        }
        .padding()
    }
}

هذا المثال يوضح لك الفكرة الأساسية: واجهة بسيطة، إدخال بيانات، ثم إرسالها إلى Firestore من خلال Repository.

التعامل مع الأخطاء الشائعة

ربط Swift بFirebase يبدو سهلاً عندما تسير الأمور بشكل طبيعي، لكن في الواقع ستواجه بعض الأخطاء المتكررة. من الأفضل أن تتعرف عليها مبكراً.

أول خطأ شائع هو نسيان استدعاء FirebaseApp.configure(). بدونها لن تعمل الخدمة.

الخطأ الثاني هو عدم وضع ملف GoogleService-Info.plist في المشروع أو وضعه في Target خاطئ.

الخطأ الثالث هو تفعيل Firestore من لوحة Firebase ثم نسيان إعداد Security Rules بشكل مناسب، فيظهر لك خطأ permission denied.

الخطأ الرابع هو محاولة تحويل البيانات إلى Codable مع عدم تطابق أسماء الحقول بين Swift وFirestore. يجب أن تكون الأسماء واضحة، أو تستخدم mapping مناسباً.

الخطأ الخامس هو تنفيذ تحديثات الواجهة على thread غير رئيسي. بعد استرجاع البيانات من Firebase، يجب غالباً تحديث واجهة المستخدم على DispatchQueue.main.async.

Security Rules: أهم جزء لا يجب تجاهله

كثير من المطورين يتعلمون Firestore CRUD لكن يتجاهلون Security Rules، ثم يكتشفون أن أي شخص يستطيع الوصول إلى البيانات بطريقة غير مرغوبة. قواعد الأمان ليست تفصيلاً ثانوياً؛ هي جزء أساسي من أي مشروع حقيقي.

مثال بسيط لقواعد Firestore

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /tasks/{taskId} {
      allow read, write: if request.auth != null;
    }
  }
}

هذه القاعدة تسمح فقط للمستخدمين المسجلين بالدخول والقراءة والكتابة. لكنها عامة جداً، وقد لا تكون مناسبة لتطبيق حقيقي متعدد المستخدمين. غالباً ستحتاج إلى ربط كل مستند بـ uid والتأكد أن المستخدم لا يرى إلا بياناته.

مثال أكثر تحديداً

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /tasks/{taskId} {
      allow create: if request.auth != null
                    && request.resource.data.ownerId == request.auth.uid;

      allow read, update, delete: if request.auth != null
                    && resource.data.ownerId == request.auth.uid;
    }
  }
}

بهذا الشكل تحمي البيانات بحيث لا يتمكن أي مستخدم من تعديل بيانات لا تخصه.

ربط البيانات بالمستخدم الحالي

حين يكون التطبيق متعدد المستخدمين، ينبغي أن تحفظ ownerId مع كل سجل. مثال:

struct Task: Codable, Identifiable {
    @DocumentID var id: String?
    var ownerId: String
    var title: String
    var details: String
    var isDone: Bool
    var createdAt: Date
}

ثم عند إضافة المهمة:

func addTaskForCurrentUser(title: String, details: String, completion: @escaping (Result<Void, Error>) -> Void) {
    guard let uid = Auth.auth().currentUser?.uid else {
        completion(.failure(NSError(domain: "NoUser", code: 401)))
        return
    }

    let task = Task(
        ownerId: uid,
        title: title,
        details: details,
        isDone: false,
        createdAt: Date()
    )

    do {
        _ = try Firestore.firestore().collection("tasks").addDocument(from: task) { error in
            if let error = error {
                completion(.failure(error))
            } else {
                completion(.success(()))
            }
        }
    } catch {
        completion(.failure(error))
    }
}

وبعدها تستطيع جلب مهام المستخدم الحالي فقط:

func fetchCurrentUserTasks(completion: @escaping (Result<[Task], Error>) -> Void) {
    guard let uid = Auth.auth().currentUser?.uid else {
        completion(.success([]))
        return
    }

    Firestore.firestore()
        .collection("tasks")
        .whereField("ownerId", isEqualTo: uid)
        .getDocuments { snapshot, error in
            if let error = error {
                completion(.failure(error))
                return
            }

            let tasks = snapshot?.documents.compactMap { try? $0.data(as: Task.self) } ?? []
            completion(.success(tasks))
        }
}

العمل مع Realtime Database: هل هي بديل مناسب؟

Firestore هو الخيار الأكثر شيوعاً في الوقت الحالي، لكن Firebase Realtime Database لا يزال موجوداً ويُستخدم في بعض المشاريع. الفرق الأساسي أن Realtime Database يعتمد على JSON tree واحد كبير، بينما Firestore يعتمد على Documents وCollections بشكل أكثر مرونة وتنظيماً.

إذا كان تطبيقك يحتاج بنية بيانات حديثة، واستعلامات أفضل، وتوسعاً أسهل، فـ Firestore غالباً هو الخيار الأفضل. أما إذا كان لديك مشروع قديم أو بنية محددة تعتمد عليه، فقد يكون من المنطقي الاستمرار مع Realtime Database.

في هذا المقال ركزنا على Firestore لأنه الأقرب لما يحتاجه أغلب مطوري Swift اليوم.

التعامل مع الإنترنت الضعيف والوضع غير المتصل

واحدة من أجمل مزايا Firestore أنه يدعم العمل دون اتصال جزئياً عبر التخزين المؤقت المحلي. هذا يعني أن بعض العمليات قد تبدو للمستخدم سريعة حتى مع ضعف الشبكة. لكن لا تعتمد على ذلك بشكل أعمى. في الواجهات الحساسة يجب أن توضح للمستخدم حالة الاتصال عند الضرورة.

عند تصميم التطبيق، حاول أن تتوقع ما الذي يحدث لو انقطع الإنترنت أثناء الحفظ. هل ستعرض رسالة؟ هل ستؤجل الحفظ؟ هل ستعيد المحاولة؟ هذه التفاصيل الصغيرة تصنع فرقاً كبيراً في تجربة المستخدم.

الأداء والتنظيم

عندما يبدأ التطبيق بالنمو، يصبح الأداء مهماً جداً. لا تجلب كل البيانات بلا حدود. استخدم pagination عندما يكون العدد كبيراً. لا تعرض استعلامات غير مفلترة في شاشة رئيسية تحتوي آلاف السجلات. واستخدم الفهارس المناسبة عندما يطلب Firestore منك ذلك.

كذلك، لا تجعل الواجهة تعتمد مباشرة على استدعاء البيانات كل مرة من الصفر إذا لم يكن هناك داعٍ. ضع منطق الكاش، والتحميل التدريجي، والتحديث عند الحاجة فقط.

بناء تطبيق حقيقي بطريقة سليمة

في المشاريع الواقعية، ستحتاج عادة إلى هذا الترتيب:

مصادقة المستخدم أولاً.

تحديد بيانات المستخدم داخل Firestore.

إنشاء Repository للتعامل مع Firestore.

إنشاء ViewModel أو ObservableObject أو Presenter.

ربط الواجهة بالبيانات.

إضافة رسائل الخطأ، والتحميل، والحالات الفارغة.

هذا الترتيب البسيط يحميك من الفوضى لاحقاً. كثير من المشاريع تبدأ بخطوات متفرقة ثم يصعب تعديلها. لكن عندما تبني من البداية بطريقة منظمة، تستطيع إضافة ميزات جديدة بسهولة أكبر.

مثال على بنية مشروع مقترحة

يمكنك تنظيم المشروع هكذا:

Models/Task.swift

Services/TaskService.swift

ViewModels/TaskViewModel.swift

Views/TaskListView.swift

Views/AddTaskView.swift

Helpers/Extensions.swift

هذه البنية ليست إلزامية، لكنها عملية جداً. ومع الوقت ستشعر أن الفصل بين الملفات يوفر عليك الكثير من الجهد الذهني.

نصائح مهمة عند ربط Swift مع Firebase

لا تخزن بيانات حساسة داخل Firestore من دون قواعد أمان واضحة.

لا تعتمد على أسماء حقول عشوائية؛ حافظ على naming ثابت.

اجعل Date حقيقية وليس نصوصاً متفرقة.

جرّب دائماً السيناريوهات الفاشلة، وليس فقط النجاح.

استخدم completion أو async/await بطريقة مناسبة حسب نسخة Swift التي تعمل بها.

إذا كان مشروعك حديثاً جداً، يمكنك التفكير في async/await لجعل الكود أكثر وضوحاً. ومع ذلك، يجب أن تتأكد من توافق البنية مع SDK المستخدم.

مثال حديث باستخدام async/await بشكل مبسط

import FirebaseFirestore
import FirebaseFirestoreSwift

final class AsyncTaskRepository {
    private let db = Firestore.firestore()

    func addTask(_ task: Task) async throws {
        _ = try db.collection("tasks").addDocument(from: task)
    }

    func fetchTasks() async throws -> [Task] {
        let snapshot = try await db.collection("tasks").getDocuments()
        return snapshot.documents.compactMap { try? $0.data(as: Task.self) }
    }
}

هذا الشكل نظيف جداً، خصوصاً إذا كان مشروعك يعتمد على Swift الحديث. لكنه يحتاج إلى فهم جيد لإدارة الأخطاء والتزامن.

ما الفرق بين الكود النظيف والكود الذي يعمل فقط؟

الكود الذي يعمل فقط ينجز المهمة الحالية. أما الكود النظيف فيسمح لك بفهمه بعد شهر، وتعديله بعد ستة أشهر، وتسليمه لفريق آخر بعد سنة. وعندما تعمل مع Firebase داخل Swift، سترى أن الاختصار في البداية قد يصبح عبئاً كبيراً لاحقاً إن لم تنظّم الطبقات جيداً.

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

متى تختار Firebase ومتى لا تختاره؟

Firebase ممتاز عندما تريد سرعة في الإطلاق، أو مزامنة فورية، أو بنية خفيفة، أو تطبيقاً متوسّطاً لا يحتاج تعقيد Backend كبير. وهو رائع أيضاً للمطور الفردي أو الفريق الصغير.

أما إذا كان مشروعك يتطلب تحكمًا دقيقًا جداً في الاستعلامات المعقدة، أو منطق أعمال شديد التفصيل، أو تكاملاً عميقاً مع نظام داخلي كبير، فقد تحتاج إلى Backend مخصص أو Hybrid architecture تجمع بين Firebase وخادم خاص.

خاتمة

ربط تطبيقات Swift بقاعدة بيانات Firebase ليس مجرد خطوة تقنية، بل هو قرار معماري يساعدك على بناء تطبيقات أسرع وأكثر تفاعلاً. ومع Firestore وAuthentication وSwift الحديث، تستطيع إنشاء تجربة قوية ومريحة للمستخدم من دون التعقيد المعتاد في بناء backend كامل من البداية.

أجمل ما في هذا المسار أنك تستطيع البدء بسيطاً جداً، ثم تتوسع تدريجياً. أنشئ مشروع Firebase، أضف ملف الإعدادات، فعّل Firestore، اكتب نموذج بيانات نظيف، ثم ابنِ طبقة خدمة واضحة، وبعدها اربط كل شيء بالواجهة. ومع كل خطوة، حاول أن تفكر ليس فقط: “كيف أجعل الكود يعمل؟” بل أيضاً: “كيف أجعله مفهوماً وآمناً وقابلاً للتوسع؟”

قد يبدو Firebase في البداية كأنه مجرد قاعدة بيانات سريعة، لكنه في الواقع بوابة كاملة لبناء تطبيقات iOS عملية وحديثة. وإذا تعاملت معه بعقلية منظمة، فستجد أنه يختصر عليك وقتاً كبيراً ويمنحك مساحة أكبر للتركيز على ما يهم فعلاً: تجربة المستخدم، جودة المنتج، وفكرة التطبيق نفسها.