Unowned Reference: یہ کیا ہے، نحو اور موبائل ایپلیکیشنز میں استعمال

Unowned Reference کیا ہے؟

Unowned Reference ARC میں کسی آبجیکٹ کا غیر مالکانہ حوالہ ہے جو اس کا retain count نہیں بڑھاتا۔ weak کے برعکس، unowned حوالہ آبجیکٹ کے ڈی لوکیشن کے بعد صفر نہیں ہوتا: یہ پہلے سے آزاد شدہ میموری کی طرف اشارہ کرتا رہتا ہے۔ ایسے حوالے تک رسائی EXC_BAD_ACCESS کے ساتھ رن ٹائم کریش کا سبب بنتی ہے۔

“بے مالک” کی اصطلاح معنی کی عکاسی کرتی ہے: آبجیکٹ موجود ہے، لیکن اس کی زندگی کی مدت کا کوئی ذمہ دار نہیں۔ ڈیولپر واضح طور پر اعلان کرتا ہے: “میں ضمانت دیتا ہوں کہ یہ آبجیکٹ اس وقت تک زندہ رہے گا جب تک میں اسے حوالہ دیتا ہوں۔” مرتبان اس ضمانت کی تصدیق نہیں کرتا — یہ ڈیولپر سطح پر ایک معاہدہ ہے۔

Swift.org Documentation, 2026 کے مطابق، ضمانت شدہ زندگی کے منظرناموں میں unowned حوالہ جات weak پر ترجیح دیے جاتے ہیں کیونکہ وہ: اختیاری قسم کی ضرورت نہیں رکھتے (صاف کوڈ)، unwrap کی ضرورت نہیں رکھتے (کم force-unwrap یا guard let)، اور صفر کرنے والی weak جدول کی دیکھ بھال کا کوئی اضافی بوجھ نہیں رکھتے۔ تاہم، معاہدے کی کوئی بھی خلاف ورزی کریش پر منتج ہوتی ہے۔

Swift میں unowned نحو

Swift میں، unowned حوالہ جات let یا var سے پہلے کلیدی لفظ unowned کے ساتھ اعلان کیے جاتے ہیں۔ weak کے برعکس، unowned let اور var دونوں ہو سکتا ہے، اور اختیاری قسم کی ضرورت نہیں رکھتا۔ یہ خصوصیت unowned کو ان حوالوں کے لیے آسان بناتی ہے جو ڈومین منطق کے مطابق nil نہیں ہو سکتے۔

class Country {
    let name: String
    var capital: City!           // ابتداء کے بعد سیٹ کیا جائے گا
    init(name: String) { self.name = name }
}

class City {
    let name: String
    unowned let country: Country   // ✅ unowned let — زندگی کی ضمانت

    init(name: String, country: Country) {
        self.name = name
        self.country = country
    }
}

// استعمال
let france = Country(name: "France")
let paris = City(name: "Paris", country: france)
france.capital = paris
// ✅ Country → City (strong), City → Country (unowned) — کوئی retain cycle نہیں

اس مثال میں، City unowned let country — ایک شہر ملک کے بغیر موجود نہیں رہ سکتا۔ اگر ملک غائب ہو جائے تو شہر (اور حوالہ) اپنا معنی کھو دیتے ہیں۔ معنوی طور پر، یہ unowned کے لیے ایک مثالی صورت ہے: زندگی کی ضمانت موجود ہے، اختیاری کی ضرورت نہیں، retain cycle پیدا نہیں ہوتا۔

unowned var

unowned var کی اجازت ہے لیکن کم عام ہے۔ یہ اس وقت استعمال ہوتا ہے جب حوالہ تبدیل کیا جا سکتا ہے (مثال کے طور پر، بچے کو مختلف والدین سے دوبارہ منسلک کرنا)。 دوبارہ تفویض پر، پرانے آبجیکٹ کا ڈی لوکیشن بیرونی مالک کی ذمہ داری ہے۔

Unowned Optional

Swift 5.0+ میں، unowned اختیاری (unowned let x: Type?) کے لیے معاونت متعارف کرائی گئی۔ یہ ایک سمجھوتہ ہے: unowned ضمانت دیتا ہے کہ اگر حوالہ nil نہیں ہے تو آبجیکٹ زندہ ہے۔ ڈی لوکیشن پر رویہ کریش ہے، جیسا کہ عام unowned کے ساتھ۔

Unowned vs Weak: کب کیا استعمال کریں

unowned اور weak کے درمیان انتخاب Swift آرکیٹیکچر ڈیزائن کرتے وقت کثرت سے کیے جانے والے فیصلوں میں سے ایک ہے۔ آئیے ہر صورت کے معیار اور سفارشات کا جائزہ لیتے ہیں۔

عملی اصول

weak استعمال کریں اگر آبجیکٹ کی زندگی کے بارے میں ذرا بھی شک ہو۔ Weak محفوظ، واضح ہے اور ثبوت کی ضرورت نہیں رکھتا۔ unowned استعمال کریں صرف اس وقت جب آپ ان تمام منظرناموں کو مسترد کر سکیں جن میں آبجیکٹ پہلے آزاد ہو سکتا ہے۔ عام صورتیں: بچہ جو والدین کے بغیر موجود نہیں؛ closure جو ہم وقت طور پر عمل میں آتا ہے؛ اپنے ابتدا کار کے اندر آبجیکٹ تک رسائی۔

Airbnb Swift Style Guide, 2025 کے مطابق، بڑے کوڈ بیسز میں ڈیفالٹ طور پر weak استعمال کرنے اور unowned صرف واضح تبصرے کے ساتھ استعمال کرنے کی سفارش کی جاتی ہے جو زندگی کی ضمانت کی وضاحت کرے۔ یہ تنظیم نو کے دوران غیر واضح کریش کے خطرے کو کم کرتا ہے۔

Closures میں Unowned self

Closures والدین-بچے کے تعلقات کے بعد unowned کا دوسرا سب سے زیادہ استعمال شدہ منظرنامہ ہے۔ کیپچر کی فہرست [unowned self] اس وقت استعمال ہوتی ہے جب ضمانت ہو کہ self closure سے زیادہ زندہ رہتا ہے۔ آئیے صحیح اور غلط منظرناموں کا جائزہ لیتے ہیں۔

unowned self کب محفوظ ہے

ہم وقت closures — sorted, filter, map۔ یہ موجودہ تھریڈ میں فوری عمل میں آتے ہیں، self یقینی طور پر زندہ ہے۔ unowned کے ساتھ کیپچر فہرست یہاں قابل قبول ہے اور صاف کوڈ دیتی ہے۔

class DataProcessor {
    var items: [Int] = [3, 1, 4, 1, 5]

    func processSorted() {
        // ✅ unowned self — sorted ہم وقت طور پر عمل میں آتا ہے، self ضمانتی طور پر زندہ
        let sorted = items.sorted { [unowned self] a, b in
            return self.customCompare(a, b)
        }
    }

    func customCompare(_ a: Int, _ b: Int) -> Bool { return a < b }
}

unowned self کب خطرناک ہے

غیر ہم وقت closures — تاخیر، نیٹ ورک کی درخواستیں، اینیمیشن کے ساتھ۔ closure کے شیڈول اور اس کے عمل کے درمیان self آزاد ہو سکتا ہے۔ یہاں unowned self کریش کی طرف لے جاتا ہے۔ [weak self] استعمال کریں۔

class NetworkLoader {
    func loadData() {
        // ❌ خطرناک: غیر ہم وقت closure میں unowned self
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // اگر self آزاد ہو تو کریش
        }.resume()
    }

    func handleResponse(_ data: Data?) { }

    // ✅ درست: weak self + guard
    func loadDataSafe() {
        URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in
            guard let self else { return }
            self.handleResponse(data)
        }.resume()
    }
}

اصول یاد رکھیں: unowned self — صرف ہم وقت closures کے لیے جو فوری عمل میں آتے ہیں۔ غیر ہم وقت closures کے لیے، ہمیشہ weak self + guard let استعمال کریں۔ مستثنیٰ: اگر آپ closure کے مکمل ہونے تک واضح طور پر آبجیکٹ کا حوالہ رکھتے ہیں (مثال کے طور پر، کسی دوسرے متغیر میں مضبوط حوالہ رکھ کر)۔

Unowned کے خطرات اور ان سے بچاؤ

Unowned ایک طاقتور لیکن خطرناک ہتھیار ہے۔ آئیے حقیقی دنیا کے منظرنامے دیکھتے ہیں جہاں unowned کریش کا سبب بن سکتا ہے اور خطرہ کم سے کم کرنے کے طریقے۔

تنظیم نو اور ضمانتوں کی تبدیلی

unowned کا سب سے بڑا خطرہ کاروباری منطق میں تبدیلی ہے جو زندگی کی ضمانت کو باطل کر دیتی ہے۔ ایک ڈیولپر کوڈ کی تنظیم نو کرتا ہے: ملکیت بدلتا ہے، مؤخر آزادی متعارف کراتا ہے، کیشنگ شامل کرتا ہے — اور unowned حوالہ ٹائم بم بن جاتا ہے۔ مرتبان خبردار نہیں کرے گا — صرف صارف کے آلے پر کریش۔

سفارش: unowned صرف اس وقت استعمال کریں جب زندگی کی ضمانت واضح اور دستاویزی ہو۔ ہر unowned میں تبصرہ شامل کریں: یہ حوالہ کیوں محفوظ ہے اور کن حالات میں اس کی خلاف ورزی ہو سکتی ہے۔

UIKit درجہ بندی میں Unowned

UIKit unowned کے لیے اعلی خطرہ والا علاقہ ہے۔ ViewController نیویگیشن (pop, dismiss)، میموری ان لوڈنگ، یا سمت تبدیلیوں کے دوران کسی بھی وقت آزاد ہو سکتا ہے۔ اگر آپ ViewController کو unowned self کے ساتھ closure میں منتقل کرتے ہیں، تو پس منظر سے واپسی یا اینیمیشن مکمل ہونے پر self nil ہو سکتا ہے۔

بہترین طریقے

unowned استعمال کرتے وقت خطرہ کم کرنے کے لیے، ان اصولوں پر عمل کریں:

• ڈیفالٹ طور پر weak کو ترجیح دیں — weak محفوظ ہے، unowned ایک اصلاح ہے، معیار نہیں
• ضمانتیں دستاویزی کریں — ہر unowned کے لیے، جواز کے ساتھ تبصرہ لکھیں
• ViewController میں unowned سے گریز کریں — UIKit کا زندگی کا چکر unowned ضمانتوں کے لیے غیر متوقع ہے
• unowned صرف ہم وقت closures کے لیے استعمال کریں — sorted, filter, map محفوظ امیدوار ہیں
• کوڈ کے جائزے کے دوران چیک کریں — ہر unowned کو کوڈ مصنف سے جواز کی ضرورت ہے
• معمولی شک پر weak پر جائیں — پڑھنے کی اہلیت میں نقصان (ایک guard let) پروڈکشن میں کریش سے بہتر ہے

// مثال: واضح جواز کے ساتھ دستاویزی unowned حوالہ
class InvoiceLineItem {
    let productName: String
    let price: Decimal

    // unowned Invoice — InvoiceLineItem Invoice کے بغیر موجود نہیں رہ سکتا۔
    // Invoice Item بناتا ہے اور اسے حذف ہونے پر ہٹا دیتا ہے۔
    // ضمانت: Invoice کم از کم اتنا زندہ رہتا ہے جتنا Item۔
    unowned let invoice: Invoice

    init(productName: String, price: Decimal, invoice: Invoice) {
        self.productName = productName
        self.price = price
        self.invoice = invoice
    }
}

// یہ مضبوط ضمانت ہے: Invoice deinit میں تمام Items ہٹا دیتا ہے۔
// ضمانت کی خلاف ورزی = کاروباری منطق میں ایک بگ جسے ٹھیک کرنے کی ضرورت ہے۔

ضمانتوں کی دستاویز کرنا ایک پیشہ ورانہ معیار ہے۔ بڑے منصوبوں (Airbnb, Uber) میں، کوڈ کا جائزہ ہر unowned کے لیے جواز طلب کرتا ہے۔ اگر ضمانت واضح نہیں ہے تو weak استعمال کریں۔ unowned پر تبصرہ مستقبل کے ڈیولپرز کو یہ سمجھنے میں مدد کرتا ہے کہ یہاں weak کیوں استعمال نہیں کیا گیا اور کون سی حالتیں ضمانت کو توڑ سکتی ہیں۔