Unowned Reference: шта је то, синтакса и примена у мобилним апликацијама

Шта је Unowned Reference?

Unowned Reference — је невласничка референца на објекат у ARC-у која не повећава његов retain count. За разлику од weak, unowned се не нулира након деалокације објекта: наставља да показује на меморијску област која је већ ослобођена. Позивање на такву референцу изазива runtime crash са EXC_BAD_ACCESS.

Термин „без власника“ одражава семантику: објекат постоји, али нико не одговара за његов животни век. Програмер изричито изјављује: „гарантујем да ће овај објекат бити жив док се позивам на њега“. Компајлер не проверава ову гаранцију — то је уговор на нивоу програмера.

Према Swift.org Documentation, 2026, unowned референце су пожељније од weak у сценаријима са гарантованим животним веком, јер: не захтевају опционални тип (чистији код), не захтевају unwrap (мање force-unwrap или guard let) и немају додатне трошкове за одржавање zeroing weak-табеле. Међутим, било какво кршење уговора — crash.

Синтакса unowned у Swift-у

У Swift-у unowned референце се декларишу кључном речју unowned испред let или var. За разлику од 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: гаранција животног века постоји, optional није потребан, retain cycle не настаје.

unowned var

unowned var је дозвољено, али се ређе среће. Користи се када референца може бити замењена (нпр. превезивање детета на другог родитеља). При замени, ослобађање старог објекта — одговорност спољног власника.

Unowned Optional

У Swift 5.0+ појавила се подршка за unowned optional (unowned let x: Type?). То је компромис: unowned гарантује да ако референца није nil, објекат је жив. Понашање при ослобађању — crash, као и код обичног unowned-а.

Unowned vs Weak: када користити шта

Избор између unowned и weak — једна од честих одлука при пројектовању Swift архитектуре. Размотримо критеријуме и препоруке за сваки случај.

Практично правило

Користите weak ако постоји и најмања сумња у животни век објекта. Weak је безбедан, разумљив и не захтева доказе. Користите unowned само када сте искључили све сценарије у којима објекат може бити ослобођен раније. Типични случајеви: дете које не постоји без родитеља; затварање које се извршава синхроно; позивање на објекат у оквиру његовог иницијализатора.

Према Airbnb Swift Style Guide, 2025, у великим базама кода препоручује се коришћење weak подразумевано, а unowned — само са изричитим коментаром који објашњава гаранцију животног века. Ово смањује ризик од неочигледних крашева при рефакторисању.

Unowned self у затварањима

Затварања (closures) — други по учесталости сценариј употребе unowned-а после parent-child односа. Capture list [unowned self] примењује се када је загарантовано да self живи дуже од затварања. Размотримо исправне и неисправне сценарије.

Када је unowned self безбедан

Синхрона затварања — sorted, filter, map. Извршавају се одмах у тренутној нити, self је сигурно жив. Capture list са 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 опасан

Асинхрона затварања — са кашњењем, мрежним захтевима, анимацијама. Self може бити ослобођен између постављања затварања и његовог извршавања. Овде unowned self → crash. Користите [weak self].

class NetworkLoader {
    func loadData() {
        // ❌ ОПАСНО: unowned self у асинхроном затварању
        URLSession.shared.dataTask(with: url) { [unowned self] data, _, _ in
            self.handleResponse(data)  // CRASH ако је 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 — само за синхрона затварања која се извршавају одмах. За асинхрона — увек weak self + guard let. Изузетак: ако изричито држите референцу на објекат до завршетка затварања (нпр. чувањем снажног захвата у другој променљивој).

Ризици unowned-а и како их избећи

Unowned — моћан, али опасан алат. Размотримо реалне сценарије у којима unowned може довести до краша и методе минимизације ризика.

Рефакторисање и промена гаранција

Главни ризик unowned-а — промена пословне логике при којој гаранција животног века престаје да важи. Програмер рефакторише код: мења власништво, уводи одложено ослобађање, додаје кеширање — и unowned референца постаје бомба са одложеним дејством. Компајлер неће упозорити — само crash на уређају корисника.

Препорука: користите unowned само када је гаранција животног века очигледна и документована. Додајте коментар уз сваки unowned: зашто је ова референца безбедна и под којим условима може бити нарушена.

Unowned у UIKit хијерархијама

UIKit — зона повишеног ризика за unowned. ViewController може бити ослобођен у било ком тренутку при навигацији (pop, dismiss), истовару из меморије, промени оријентације. Ако прослеђујете ViewController у затварање са unowned self — при повратку из позадине или завршетку анимације self може бити nil.

Најбоље праксе

Да бисте смањили ризик при коришћењу unowned-а, следите ова правила:

• Преферирајте weak подразумевано — weak је безбедан, unowned је оптимизација, а не стандард
• Документујте гаранције — уз сваки unowned пишите коментар са образложењем
• Избегавајте unowned у ViewController-у — UIKit животни циклус је непредвидив за unowned гаранције
• Користите unowned само за синхрона затварања — sorted, filter, map — безбедни кандидати
• Проверавајте при code review — сваки unowned захтева образложење од аутора кода
• Мигрирајте на weak при најмањој сумњи — губитак у читљивости (један guard let) мањи је од crash-а у продукцији

// Пример: документована 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 брише све Item у deinit.
// кршење гаранције = грешка у пословној логици коју треба поправити.

Документовање гаранција — професионални стандард. У великим пројектима (Airbnb, Uber) code review захтева образложење сваког unowned-а. Ако гаранција није очигледна — користите weak. Коментар уз unowned помаже будућим програмерима да разумеју зашто овде нема weak-а и који услови могу нарушити гаранцију.