SwiftUI Savol-Javoblar (Chuqur)

Interview Savollari

Middle va Senior iOS Muhandislari Uchun Texnik Intervyu Qo'llanmasi: SwiftUI, Concurrency, Xotira Boshqaruvi va Core Logic

Zamonaviy iOS dasturlash ekotizimi uzluksiz ravishda murakkablashib bormoqda, bu esa Middle va Senior darajadagi muhandislardan nafaqat yuqori darajadagi API'larni bilishni, balki tizim arxitekturasi, xotira boshqaruvi mexanizmlari, asinxron dasturlash asoslari hamda hisoblash resurslarini (CPU, RAM) optimallashtirishni chuqur tushunishni talab qiladi. Ushbu keng qamrovli texnik hisobot SwiftUI, Swift Concurrency, Grand Central Dispatch (GCD), Automatic Reference Counting (ARC) va dastur arxitekturasi (Core Logic) bo'yicha mutaxassislar darajasidagi 60 ta chuqurlashtirilgan tahliliy savollar va ularning batafsil javoblarini taqdim etadi. Barcha konseptual tushuntirishlar o'zbek tilida, sohadagi standart texnik terminologiya (ingliz tilida) saqlangan holda bayon qilingan.

SwiftUI UI Rendering va Layout Mexanizmlari

SwiftUI an'anaviy UIKit'dan tubdan farq qiluvchi Declarative UI (deklarativ interfeys) paradigmasiga asoslangan bo'lib, View'larning chizilishi, State boshqaruvi va AttributeGraph ishlash mexanizmlari o'ziga xos tarzda amalga oshiriladi.

1\. Declarative UI va Imperative UI o'rtasidagi fundamental arxitektura farqi nimada va SwiftUI bu konsepsiyani qanday amalga oshiradi?

Declarative UI yondashuvida muhandis UI ning yakuniy holatini (end state) tasvirlaydi, uni qanday o'zgartirish kerakligini aniq ketma-ketlikda ko'rsatmaydi. Imperative UI (masalan, UIKit) da esa interfeysni yaratish va holatni o'zgartirish uchun qadamma-qadam ko'rsatmalar yoziladi. SwiftUI @State, @Binding va boshqa property wrapper'lar yordamida ma'lumotlar o'zgarishini kuzatib boradi va ma'lumot o'zgarganda View'larni avtomatik ravishda qayta render qiladi.1 Ushbu yondashuvning asosiy maqsadi boilerplate kodni qisqartirish va UI hamda ma'lumotlar o'rtasidagi nomuvofiqliklarni (state mismatch) tizim darajasida yo'q qilishdir.

struct DeclarativeExampleView: View {  
    @State private var isActive = false  
    var body: some View {  
        Button(action: { isActive.toggle() }) {  
            Text(isActive ? "Active State" : "Inactive State")  
               .foregroundColor(isActive ? .green : .red)  
        }  
    }  
}

Arxitektura jihatidan qaraganda, tizim State'ni Yagona Haqiqat Manbai (Single Source of Truth) sifatida qabul qiladi. Bu shuni anglatadiki, dasturda UI qismini bevosita o'zgartirish imkonsiz; faqatgina State o'zgartiriladi va tizimning render dvigateli qolgan barcha vizual o'zgarishlarni o'zi sinxronlashtiradi.

2\. Nega SwiftUI arxitekturasida View'lar uchun Class o'rniga Struct ishlatilishi qat'iy belgilangan?

Struct'lar (Value types) heap xotirasi o'rniga stack xotirasida alokatsiya qilinadi, bu esa ularni yaratish va xotiradan tozalashni nihoyatda tezlashtiradi. UIKit'da har bir UIView ob'ekti o'zida ko'plab xossalar va metodlarni saqlaydigan, katta xotira sarflaydigan obyekt hisoblanadi. SwiftUI'da esa View'lar shunchaki ma'lumotlar strukturasi bo'lib, ularning og'irligi deyarli yo'q darajadadir.2 Struct'larning immutable (o'zgarmas) tabiati va value semantics tamoyillari SwiftUI render dvigateliga faqat o'zgargan View'larni farqlash uchun diffing algoritmini yengil ishlashiga imkon beradi. Agar View class bo'lganida, xotiradagi reference'larni kuzatish va ulardagi o'zgarishlarni chuqur tekshirish CPU uchun halokatli darajada katta yuklama bo'lar edi. Struct'lar orqali SwiftUI funksional dizayn naqshlarini (functional design approach) muvaffaqiyatli tatbiq etadi.

3\. SwiftUI AttributeGraph nima va u render tsiklida qanday markaziy rolni o'z zimmasiga oladi?

SwiftUI View daraxtini to'g'ridan-to'g'ri yangilamaydi. Buning o'rniga u AttributeGraph deb nomlangan, ichki C++ tizimida yozilgan mexanizmdan foydalanadi. AttributeGraph View'larning state'lari va ularning qaramliklari (dependencies) o'rtasidagi murakkab bog'liqlik grafini quradi.3 Qachonki biron bir state o'zgarsa, AttributeGraph butun daraxtni emas, faqatgina shu state'ga to'g'ridan-to'g'ri bog'langan View'larning tugunlarini (nodes) "ifloslangan" (dirty) deb belgilaydi va faqat o'shalarni qayta hisoblab chiqadi. Ushbu AttributeGraph arxitekturasi SwiftUI ga body ichida juda tezkor hisob-kitob amalini bajarishga yordam beradi. Natijada batareya quvvati va CPU resurslari keskin tejaladi, chunki faqatgina ekranda vizual o'zgarish qilishi kerak bo'lgan komponentlargina render zanjiriga kiradi.

4\. SwiftUI Layout tizimida Proposal, Sizing va Placement algoritmlari qanday tartibda ishlaydi?

SwiftUI layout mexanizmi qat'iy uch bosqichli muzokara jarayoniga asoslangan bo'lib, ota va bola View'lar o'rtasida amalga oshiriladi:

1. Proposal (Taklif qilish): Ota View o'zining mavjud bo'sh joyidan kelib chiqib, bola View'ga ma'lum bir o'lchamni taklif qiladi.
2. Sizing (O'lchamni hisoblash): Bola View o'zining ichki kontentiga va qoidalariga qarab, o'ziga qancha joy kerakligini hisoblaydi va o'zining yakuniy o'lchamini ota View'ga qaytaradi.
3. Placement (Joylashtirish): Ota View o'zining koordinatalar tizimida bola View'ni tegishli joyga joylashtiradi.5 Ushbu arxitekturada eng muhim prinsip shuki, bola View har doim o'zining yakuniy o'lchamini o'zi hal qiladi, ota View uni majburlay olmaydi. Shuning uchun .frame(width: 100\) modifier'i aslida View'ning o'zini o'zgartirmaydi, balki uning atrofida o'lchami qat'iy 100 bo'lgan yangi yashirin ota View yaratadi.

5\. @StateObject va @ObservedObject property wrapper'larining tub farqi nimada va bu xotira boshqaruvida qanday aks etadi?

Ikkala property wrapper ham ObservableObject protokoli bilan ishlaydigan class'larni kuzatish uchun mo'ljallangan. Biroq, ularning hayot siklini (lifecycle) boshqarish usullari farqlanadi.6 @StateObject ob'ektni bevosita View ichida yaratadi va View qayta render bo'lganida ob'ektning xotirada saqlanib qolishini kafolatlaydi.1 @ObservedObject esa ob'ektning hayot sikliga javobgar emas; u faqat tashqaridan berilgan ob'ektni kuzatadi xolos.

class DataProcessor: ObservableObject {  
    @Published var dataItems: [String] = []  
}

struct ParentView: View {  
    // Ob'ektni yaratish va saqlash uchun @StateObject  
    @StateObject var processor = DataProcessor()   
    var body: some View {  
        ChildNodeView(processor: processor)  
    }  
}

struct ChildNodeView: View {  
    // Faqat tashqaridan kelgan ob'ektni kuzatish uchun @ObservedObject  
    @ObservedObject var processor: DataProcessor   
    var body: some View {  
        Text("Items: \(processor.dataItems.count)")  
    }  
}

Agar ob'ekt yaratilayotgan joyda @ObservedObject ishlatilsa, View har safar qayta chizilganda ob'ekt xotiradan o'chib, qaytadan initsializatsiya bo'lishi ehtimoli bor. Bu nafaqat unumdorlikning pasayishiga, balki ma'lumotlarning yo'qotilishiga (state reset) olib keluvchi jiddiy buglar manbaidir.

6\. @EnvironmentObject tushunchasi va uni qo'llashdagi arxitektura mezonlari

@EnvironmentObject butun ilova bo'ylab yoki ma'lum bir View ierarxiyasida global darajada ochiq bo'lgan State'ni ulashish uchun ishlatiladi. Bu yondashuv View ierarxiyasi bo'ylab har bir View'ga parametr orqali ma'lumot uzatishning (prop-drilling) oldini oladi va kodni sezilarli darajada toza saqlaydi.1 Biroq, bu qulaylik o'zining salbiy asoratlariga ega. @EnvironmentObject ni haddan tashqari ko'p ishlatish komponentlarning modullik (modularity) xususiyatini pasaytiradi. Agar biror View @EnvironmentObject talab qilsa va siz u View'ni boshqa bir ekranda qayta ishlatmoqchi bo'lsangiz, albatta o'sha Environment ob'ektini muhitga in'yeksiya qilishingiz shart. Bu esa SOLID prinsiplaridagi qaramliklarni kamaytirish (loose coupling) qoidasiga to'g'ri kelmaydi.

7\. SwiftUI View Identity mexanizmlari: Explicit va Structural Identity

SwiftUI qaysi View o'zgarganini va qaysi biri avvalgi holatida ekanligini bilish uchun View Identity (Identifikatsiya) tushunchasidan foydalanadi. Uning ikki turi mavjud:

1. Explicit Identity (Ochiq Identifikatsiya): Dasturchi tomonidan id(\_:) modifier'i yoki Identifiable protokoli orqali bevosita beriladi. Bu asosan ForEach yoki List ro'yxatlarida har bir qatorni aniq ajratib olish uchun zarur.7
2. Structural Identity (Strukturaviy Identifikatsiya): View'ning koddagi joylashuvidan (if/else shartlari yoki Switch operatorlari) kelib chiqib, SwiftUI kompilyatori o'zi yaratadigan yashirin ID.7 Transitions (o'tish animatsiyalari) aynan shu Identity asosida ishlaydi. Agar if sharti o'zgarib View g'oyib bo'lsa, tizim Structural Identity o'zgarganini sezadi va animatsiya ishga tushadi.

8\. Nega AnyView ishlatish SwiftUI arxitekturasida "Anti-Pattern" hisoblanadi?

AnyView o'z ichiga olgan View'ning haqiqiy turini (type) yashiradi, bu jarayon dasturlashda Type Erasure deb ataladi. SwiftUI kompilyatori o'z diffing algoritmi uchun View turlarining ma'lumotlariga kuchli bog'langan.

AnyView ishlatilganda, SwiftUI Structural Identity ma'lumotlarini butunlay yo'qotadi. Natijada u View'ni oddiygina yangilash o'rniga, har safar state o'zgarganda qadimgi View'ni xotiradan o'chirib, yangisini boshqatdan yaratishga (re-rendering overhead) majbur bo'ladi. Bu CPU tsikllari va xotira ob'ektlarining isrofiga, shuningdek animatsiyalarning buzilishiga olib keladi. Bunga muqobil sifatida har doim @ViewBuilder yoki Group ishlatish maqsadga muvofiqdir.

9\. State, Binding va Published wrapper'larini taqqoslash

10\. GeometryReader mexanikasi va unumdorlikka salbiy ta'siri

GeometryReader ota View tomonidan berilgan yashirin bo'sh joy o'lchamlarini va View'ning global/lokal koordinatalarini o'qish imkonini beruvchi kuchli vositadir. Biroq u o'ziga xos xavf-xatarlarga ega.

GeometryReader doimo o'ziga taqdim etilgan barcha bo'sh joyni maksimal darajada egallashga harakat qiladi. Bundan tashqari, agar u ScrollView ichida yoki murakkab animatsiyalar qatlamida joylashsa, har bir piksel o'zgarganda u qayta hisob kitob qilinadi. Ba'zi holatlarda bu yashirin qayta renderlanish (infinite layout loops) sikllarini keltirib chiqarishi mumkin. Shuning uchun uni faqat eng zarur hollardagina va imkon qadar lokalizatsiya qilingan (kichik) View'larda ishlatish lozim.

SwiftUI Performance va Optimisation Strategiyalari

Ilova murakkablashgani sari View'larning qayta chizilishi bilan bog'liq performance (unumdorlik) muammolari yuzaga chiqadi. Senior muhandislardan o'lchov vositalarini bilish va kodni optimallashtirish talab qilinadi.

11\. EquatableView nima va diffing optimallashtirishda qanday rol o'ynaydi?

Standart SwiftUI holatida, ota View qayta chizilsa, barcha bola View'lar ham qayta hisoblab chiqiladi. Agar bola View juda og'ir bo'lsa va faqatgina ma'lum bir spetsifik xossalar o'zgargandagina qayta chizilishi kerak bo'lsa, uni Equatable protokoliga moslashtirish talab etiladi. Shundan so'ng, View EquatableView (yoki .equatable() modifier) bilan o'raladi.8

struct HeavyTaskRow: View, Equatable {  
    let task: TaskModel  
      
    static func == (lhs: Self, rhs: Self) -> Bool {  
        // Faqat task statusi yoki nomi o'zgarsagina qayta render bo'ladi  
        return lhs.task.id == rhs.task.id && lhs.task.status == rhs.task.status  
    }  
      
    var body: some View {  
        // Murakkab UI elementlari...  
        Text(task.name)  
    }  
}

Ushbu metodologiyani qo'llash orqali keraksiz renderlanishning oldi olinadi. Biroq, agar \== funksiyasida yozilgan solishtirish logikasi juda ko'p qatorli yoki og'ir bo'lsa, bu solishtirish amali render qilishning o'zidan ko'proq CPU vaqtini olib qo'yishi mumkin.

12\. View'larning qayta chizilish sababini Self.\_printChanges() yordamida aniqlash

SwiftUI 15 va undan yuqori versiyalarda kiritilgan Self.\_printChanges() yashirin tizim funksiyasi bo'lib, View nima sababdan AttributeGraph tomonidan qayta render bo'layotganini konsolga chiqarib beradi.10 Bu keraksiz yangilanishlarni (unnecessary updates) debug qilishda eng kuchli vosita hisoblanadi. Agar konsolda @self changed yozuvi chiqsa, bu View'ning o'zidagi struct property'lari o'zgarganligini bildiradi. \_printChanges() faqat debug vaqtida ishlatilishi shart, chunki production kodida u kiritib qo'yilsa, I/O operatsiyasi sifatida dastur tezligini tushiradi.

13\. Instruments orqali SwiftUI profil qilish jarayoni qanday bosqichlardan iborat?

Xcode Instruments tarkibidagi "Time Profiler \+ SwiftUI" shabloni yordamida View'larning hayot siklini detallarigacha tahlil qilish mumkin.12 Asosiy profiling bosqichlari:

1. Xcode'da Product \> Profile (Cmd \+ I) ni bosish.
2. SwiftUI and Time Profiler shablonini tanlash.
3. Ilovalarda qotayotgan (hitch) ekran bo'ylab harakatlanish va Record tugmasini bosish.
4. Recordni to'xtatish va grafikdagi "Main Thread", "SwiftUI Updates" va "Allocations" yo'laklarini tekshirish.13 Instruments'da xususan "View Body" qismi qancha vaqt olayotganiga e'tibor berish muhim. iOS interfeysi ravon 60 FPS da ishlashi uchun barcha body hisob-kitoblari 16.67 millisoniya ichida tugallanishi zarur. Aks holda u CPU bottleneck'ni keltirib chiqaradi va Frame Drop kuzatiladi.

14\. List va ForEach komponentlarida id parametrining performance uchun ahamiyati

ForEach to'plamdagi har bir elementni ajratib olish va render qilish uchun unikal identifikatorni (id) qat'iy talab qiladi. Agar id sifatida \\.self berilsa va ro'yxat ob'ektlari murakkab model bo'lsa, ro'yxatni yangilash sekinlashadi.10 Identifiable protokoli orqali kafolatlangan UUID kabi qiymatlarni berish to'g'ri yechimdir. Agar ro'yxatdagi bitta element o'zgarsa, to'g'ri id berilmagan holatda SwiftUI butun ro'yxat elementlarini boshqatdan chizadi (full redraw). To'g'ri identifikatsiya qilinganda esa, AttributeGraph faqatgina o'zgargan qatorni (Row) farqlaydi va faqat shu qatorni xotirada o'zgartirib ekranga uzatadi (partial update).

15\. Flash Update Regions vositasidan qanday foydalaniladi?

Xcode'ning vizual debug vositalaridan biri bo'lgan "Flash Update Regions" orqali ilova simulatorida ishlayotganda ekrandagi qaysi hududlar (View'lar) ayni vaqtda qayta chizilayotganini ko'rish mumkin.14 Qayta chizilgan joylar yashil to'rtburchak shaklida miltillab ko'rinadi. Bu vosita arxitektura xatolarini ochib beradi. Masalan, agar siz faqat bitta matnni o'zgartirsangiz-u, butun ekran miltillasa, demak, global state (@EnvironmentObject yoki katta @ObservedObject) to'g'ri bo'laklarga bo'linmagan va u o'zgarishi bilanoq o'ziga bog'liq bo'lmagan UI qismlarini ham renderlanishga majbur qilmoqda.

16\. LazyVStack va VStack farqlari va xotira optimizatsiyasi

VStack o'z ichidagi barcha elementlarni ekranga chiqish-chiqmasligidan qat'i nazar darhol xotirada yaratib (allocate) chizib qo'yadi. Yuzlab elementlar uchun bu jarayon operativ xotirani (RAM) tezda to'ldiradi. LazyVStack esa elementlarni faqat ekranga kirish nuqtasiga kelganda (on-demand) yaratadi.

Katta ro'yxatlar va cheksiz skrolling (infinite pagination) tizimlarida har doim Lazy komponentlar (yoki List) ishlatilishi shart. Aks holda App xotiradan toshib yopilib ketishi (Out of Memory \- OOM) mumkin. E'tiborli jihati, LazyVStack skroll vaqtida yangi viewlarni hisoblagani sababli, uning ichidagi Row'lar o'ta og'ir bo'lsa, skroll vaqtida qotishlar yuzaga kelishi mumkin.

17\. Offscreen Rendering (Ekransiz renderlash) va FPS tushishi

SwiftUI View'ga .cornerRadius, .shadow, yoki mask kabi modifikatorlar qo'llanilsa, bu xususiyatlar bevosita GPU tomonidan bir marta chizilishi qiyin kechadi. Shuning uchun tizim avval ularni yashirin xotirada (offscreen buffer) pikselma-piksel hisob-kitob qilib, so'ngra tayyor tasvirni asosiy ekranga o'tkazadi.15 Bu CPU va GPU o'rtasida katta ma'lumot almashinuvini talab etuvchi qimmat operatsiyadir. Offscreen rendering'dan qochish uchun .shadow o'rniga tayyor soyali tasvirlardan foydalanish yoxud UIKit orqali shadowPath yondashuvini (faqat ma'lum doiralar uchun) tatbiq etish tavsiya etiladi.

18\. iOS 17'dagi @Observable makrosi va Property-Level Diffing

Avvalgi @Published property'lar o'zgartirilganda, garchi View ob'ektning faqat bitta xossasini o'qiyotgan bo'lsa ham, butun ObservableObject bo'yicha "o'zgarish bo'ldi" signali barcha kuzatuvchilarga jo'natilar edi. @Observable makrosi esa har bir xossani alohida (granular) kuzatish imkonini beradi.14 Bu SwiftUI'ga "Property-level diffing" (xossa darajasidagi solishtirish) ni qo'llash imkonini yaratdi. Natijada View faqat o'zi haqiqatda ishlatayotgan xossasi o'zgargandagina qayta render bo'ladi. Bu qaramliklar daraxtini keskin qisqartiradi va arxitektura darajasidagi ulkan unumdorlik sakrashidir.

19\. Task modifikatori vs onAppear hayot sikli (lifecycle) ilgaklari

.onAppear modifier'i View ekranda paydo bo'lganda oddiy sinxron yoki asinxron kodni ishga tushiradi. Ammo agar foydalanuvchi View'dan chiqib ketsa, .onAppear ichida boshlangan asinxron jarayon (masalan API so'rovi) o'z-o'zidan to'xtamaydi va xotirada davom etaveradi. .task modifier'i esa aynan asinxron kontekst bilan ishlash uchun mo'ljallangan va View ekrandan yo'qolganda avtomatik ravishda taskni cancel (bekor) qiladi.5 Bu tizim darajasida resurslarning behuda sarflanishini oldini oladi va memory leak'lardan qutqaradi.

20\. SwiftUI'da rasmlarni yuklashda xotirani qanday boshqarish kerak?

AsyncImage oson echim bo'lsa-da, u serverdan kelgan 4K rasmlarni asl o'lchamda xotiraga yuklaydi. Ekranda rasm kichik qilib ko'rsatilsa-da, RAM asl o'lchamdagi piksellar miqdoriga qarab band bo'ladi. Masalan, diskdagi 2MB lik rasm RAM'da osongina 60MB ni egallashi mumkin.15 Xotira spike'larini (keskin oshishini) oldini olish uchun CGImageSourceCreateThumbnailAtIndex kabi CoreGraphics API'laridan foydalanib, rasmni yuklash vaqtidanoq kerakli o'lchamga keltirish (Downsampling) lozim.15 Bu texnika RAM sarfini yuz barobargacha tejashi mumkin.

Swift Concurrency (Async/Await va Actors)

Swift 5.5 da kiritilgan Concurrency modeli kodni toza, chiziqli va ma'lumotlar poygasidan (Data Race) xoli bo'lishini ta'minlaydi. Senior intervyularida Thread Pool mexanikalari asosiy o'rin tutadi.

21\. Async/Await va GCD (Grand Central Dispatch) ning konseptual farqlari

GCD bu C tilida yozilgan, thread'larga va queue'larga (navbatlarga) asoslangan past darajadagi API hisoblanadi. Unda asinxron kodlar asosan callback'lar (completion handlers) yordamida yoziladi, bu esa ko'pincha "Pyramid of Doom" deyiluvchi o'qish qiyin bo'lgan kod strukturasiga va Retain Cycle xavflariga olib keladi.16 Async/Await esa Swift kompilyatori darajasiga integratsiya qilingan tuzilmaviy asinxron modeldir. U operatsion tizim blokirovkalari o'rniga, yengil task suspension (to'xtatib turish) mexanizmidan foydalanadi. GCD da 1000 ta tarmoq so'rovi yuborilsa tizim 1000 ta thread yaratishga urinishi mumkin (Thread Explosion). Async/Await esa CPU yadrolari soniga mos thread'lar miqdorini doimiy ushlab turadi va barcha 1000 ta taskni shu sanoqli thread'lar ichida navbat bilan ijro etadi.16

22\. Task ob'ektining hayot sikli va atributlar merosxo'rligi

Task Swift Concurrency'dagi ijro birligidir. Yaratilganda, Task o'zi chaqirilayotgan muhitning (context) muhim atributlarini, xususan prioritetni, task-local qiymatlarni va aktorni izolyatsiya qilish parametrlarini avtomatik ravishda meros qilib oladi.19 Agar muhandis MainActor ichida yangi Task { } ochsa, u Asosiy Thread'da qoladi. E'tiborli jihati, Task.cancel() funksiyasi ishga tushirilganda jarayon darhol uzilmaydi. U faqatgina task'ning isCancelled bayrog'ini true holatiga o'tkazadi. Dasturchining o'zi og'ir sikllar yoki API so'rovlari oldidan try Task.checkCancellation() orqali bu bayroqni tekshirib, jarayonni to'xtatishi kerak.

23\. Structured va Unstructured Concurrency qanday farqlanadi?

Structured (Tuzilmaviy) Concurrency async let va TaskGroup konstruktsiyalari yordamida yoziladi.20 Uning doirasi (scope) qat'iy aniq bo'lib, ota va bola Task'lar o'rtasida qat'iy ierarxiya mavjud bo'ladi. Ota Task xatolikka uchrasa yoki bekor qilinsa, barcha bola Task'lar avtomatik tarzda bekor qilinadi. Unstructured (Tuzilmasiz) Concurrency esa Task {} va Task.detached {} orqali yaratiladi. Ular chaqirilgan funksiya doirasidan tashqarida ham o'z hayotini davom ettiraveradi.20 Bunday yondashuvda resurslarni tozalash va taskni kerak bo'lmaganda bekor qilish mas'uliyati to'liq muhandisning zimmasiga o'tadi.

24\. Actor arxitekturasi va Data Race muammosining yechimi

Data Race — ikki yoki undan ortiq thread bir vaqtning o'zida bitta xotira manziliga yozishga uringanida kelib chiqadigan dasturlashning eng yomon xatolaridan biridir. Buni oldini olish uchun Swift'ga actor kiritildi. Actor bu class kabi reference type bo'lib, o'zining ichki holatiga bir vaqtning o'zida faqat va faqat bitta Task kirishiga ruxsat beruvchi sinxronizatsiya maydoni (isolation domain) hisoblanadi.21

actor SafeCounter {  
    private var count = 0  
    func increment() {  
        count += 1  
    }  
}

Actor o'zgaruvchisiga uning tashqarisidan yozish taqiqlanadi. O'qish yoxud metodlarini chaqirish uchun doim await ishlatish majburiydir.22 Nega? Chunki actor ayni paytda boshqa Task bilan band bo'lsa, yangi chaqiruvchi Task to actor bo'shamaguncha o'z ishini to'xtatib turishi (suspend) talab etiladi.

25\. Actor Reentrancy (Qayta kirish) xavfi nima va u qanday boshqariladi?

Garchi Actor xavfsiz bo'lsa-da, uning ichidagi funksiyalarda await chaqirilganda, u vaqtinchalik o'z faoliyatini to'xtatadi va thread'ni bo'shatadi (suspend). Shu jarayon oralig'ida Actor ochiq va qulflanmagan bo'ladi.23 Bu vaqtda butunlay boshqa Task Actor ichiga kirib, uning ma'lumotlarini o'zgartirishi mumkin. Birinchi Task kutishdan qaytganida esa u kutmagan, umuman boshqa o'zgartirilgan holatga (state) duch keladi.25 Bu asoratdan saqlanish uchun, har doim await amali tugagach, state'ning avvalgi qiymatlari saqlanib qolganmi yoki yo'qmi tekshirish kerak. Shuningdek, takroriy (masalan bitta URL'ga bo'ladigan) tarmoq so'rovlarini in-flight tasks ko'rinishida lug'atda (dictionary) saqlab, yangi so'rov kelganda avvalgisini qaytarish (Task Deduping) yaxshi usuldir.

26\. @MainActor va UI sinxronizatsiyasi

SwiftUI va UIKit tizimlari to'liq Main Thread'ga qaramdir. Orqa fondan kelgan ma'lumotlarni UI'da aks ettirish uchun @MainActor global aktori ishlatiladi.26

@MainActor  
class DashboardViewModel: ObservableObject {  
    @Published var dataList: [String] = []  
      
    func fetchData() async {  
        // networkRequest boshqa background thread'da bajarilishi mumkin  
        let result = await networkRequest()  
        // bu qator esa albatta Main Thread da ijro etilishi kafolatlanadi  
        self.dataList = result   
    }  
}

Class yoki metodlarni ushbu atribut bilan belgilash orqali kompilyator kodning doimo Asosiy Thread'da ishlashini kafolatlaydi va sizni "UI must be updated on Main Thread" kabi crash'lardan qutqaradi.19

27\. Sendable protokoli va @unchecked Sendable qo'llanilishi

Sendable bu Swift kompilyatoriga ob'ekt yoki tur (type) ning bir asinxron domendan boshqasiga uzatilishi (concurrency domain crossing) mutlaqo xavfsiz ekanligini bildiruvchi protokoldir.20 Qiymatli turlar (Struct, Enum) avtomatik Sendable hisoblanadi, chunki ular nusxalanadi. Ammo qadimiy C tilidan qolgan obyektlar yoki o'zingiz Lock'lar orqali thread-safe qilgan class'laringizni kompilyator tekshira olmaydi va xato beradi. Shunda @unchecked Sendable direktivasi orqali dasturchi mas'uliyatni o'z bo'yniga oladi. Lekin qoidalarni buzsangiz, Data Race sizning zimmangizda bo'ladi.

28\. withCheckedContinuation orqali eski kodlarni migratsiya qilish

Eski completion handler'ga asoslangan kutubxonalar yoki API'larni yangi Async/Await muhitiga moslashtirish uchun withCheckedContinuation funksiyasi qo'llaniladi.

Ushbu funksiya sizga continuation ob'ektini beradi va asinxron javob kelgach uning .resume(returning:) metodini chaqirish kerak bo'ladi. Eng qat'iy qoida shundaki: Continuation faqat va faqat BIR MARTA resume qilinishi shart. Agar u hech qachon resume qilinmasa, Task abadiy xotirada qoladi. Agar ikki marta chaqirilsa, dastur vahimali ravishda qulaydi (fatal crash).

29\. AsyncStream va Combine texnologiyalarini taqqoslash

AsyncStream vaqt o'tishi bilan ketma-ket keladigan asinxron qiymatlarni (masalan location o'zgarishlari yoki websocket xabarlari) oqim sifatida uzatish uchun ishlatiladi.20 U for await item in stream operatori orqali siklga olinadi. Garchi u Combine framework'iga o'xshasa-da, ular farqlanadi. Combine o'ta kuchli transformatsiya vositalariga (debounce, throttle, flatMap, combineLatest) ega va murakkab voqealar ierarxiyasi uchun qulay. Lekin Apple ekotizimi borgan sari Combine'dan voz kechib, Native Concurrency (AsyncStream) ga ustunlik bermoqda.20

30\. Cooperative Thread Pool ishlash mexanikasi

GCD o'z vaqtida operatsion tizimdan keragicha thread so'ray olar edi, bu xotirada thread explosion (yuzlab thread'lar yaratilishi) ga sabab bo'lardi. Har bir thread uchun 512KB xotira stack ajratilishi hisobga olinsa, bu juda qimmat jarayon. Swift Concurrency "Cooperative Thread Pool" ni joriy etdi. Unda thread'lar soni maksimal darajada CPU yadrolari soniga teng bo'ladi (masalan, 6 yadro \= 6 thread). Task'lar kutinganda (suspend) ular thread'ni bo'shatadi va boshqa Task zudlik bilan u thread'ni egallaydi.16 Agar siz CPU'ni uzoq vaqt band qiladigan, blokirovka qiluvchi (blocking) amallarni bajarsangiz, bor thread'lar tugab qoladi (thread starvation) va dastur muzlaydi.

Multithreading va Grand Central Dispatch (GCD)

Garchi Swift Concurrency e'tiborda bo'lsa-da, GCD hamon ko'plab platforma API'larining o'zagi bo'lib qolmoqda. Intervyularda navbatlar (queues) dinamikasi chuqur so'raladi.

31\. Serial va Concurrent navbatlarning (Queue) funksional farqlari

GCD vazifalarni DispatchQueue orqali boshqaradi 16:

• Serial Queue: Berilgan ishlarni faqat bittadan, navbat bilan bajaradi. Oldingi vazifa to'liq tugamaguncha keyingisi boshlanmaydi. Bu holat resurslarga xavfsiz kirish uchun juda ishonchli mexanizmdir.
• Concurrent Queue: Vazifalar bir vaqtda parallel ravishda boshlanadi va ularning tugash vaqti tizim resurslariga bog'liq ravishda turlicha bo'lishi mumkin.16 U og'ir vazifalarni qisqa vaqtda tugatish uchun qo'llaniladi.

32\. Sync va Async ijro metodlari qanday ishlaydi?

Queue turi qanday bo'lishidan qat'i nazar, vazifalar unga ikki xil yo'l bilan jo'natiladi 16:

• sync amaldagi thread'ni to'xtatib (bloklab) turadi va yuborilgan vazifa navbatda to'liq bajarib bo'linguniga qadar keyingi qator kod o'qilmaydi.28
• async esa vazifani uzoqdagi navbatga yuboradi va amaldagi thread kutib o'tirmasdan zudlik bilan o'z ishida davom etaveradi.16 Concurrent navbatga sync orqali ish yuborish ma'nosiz bo'lishi mumkin, chunki u siz kutgan paralellikni bermaydi va amaldagi thread'ni qulflaydi.16

33\. Nima uchun DispatchQueue.main.sync doimo Deadlock (Qulf) ga olib keladi?

Agar siz Asosiy Thread'da bo'lsangiz va DispatchQueue.main.sync { print("Hi") } yozsangiz, dastur osilib qoladi.16 Sababi: Asosiy thread o'zidagi sync buyrug'i sababli bloklanadi va ichidagi vazifaning tugashini kuta boshlaydi. Biroq jo'natilgan vazifa ham Asosiy navbatga (main queue) borib tushadi va u ish boshlash uchun Asosiy thread'ning bo'shashini kutadi. Ikki tomon bir-birini abadiy kutadi.

34\. Quality of Service (QoS) qanday qilib ish hajmini tartibga soladi?

Tizim qaysi navbatga ko'proq CPU vaqti va resurs berishini uning QoS darajasi orqali bilib oladi 16:

1. .userInteractive: Eng yuqori prioritet. UI animatsiyalari kabi inson ko'zi ko'rib turgan, pauzasiz ishlashi kerak bo'lgan vazifalar.
2. .userInitiated: Foydalanuvchi qandaydir tugmani bosdi va natijani kutmoqda.
3. .utility: Uzoq davom etadigan, progress bar ko'rsatilib turiladigan jarayonlar (Fayl yuklab olish).
4. .background: Foydalanuvchi bilmaydigan tizim operatsiyalari (Keshni tozalash, indeksatsiya).16

35\. DispatchWorkItem nima maqsadda qo'llaniladi va Debouncing qanday yoziladi?

DispatchWorkItem — bu GCD'da oddiy yopilishlarni (closures) o'ziga xos instansiya (obyekt) darajasiga olib chiqadigan sinfdir. Uning afzalligi vazifani yuborishdan oldin bekor qilish (cancel()) va jarayon tugagach xabarnoma (notify()) olish imkoniyatidadir.16

var searchWorkItem: DispatchWorkItem?

func performSearch(query: String) {  
    searchWorkItem?.cancel() // Avvalgi yozilganlarni bekor qilish (Debounce)  
      
    let task = DispatchWorkItem { [weak self] in  
        self?.makeNetworkRequest(for: query)  
    }  
      
    searchWorkItem = task  
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.4, execute: task)  
}

Ushbu Debounce yondashuvi serverga keraksiz so'rovlar yukini yuborishdan asraydi.16

36\. DispatchGroup orqali bir nechta tarmoq so'rovlarini birlashtirish

Agar ilovada bir nechta bir-biriga bog'liq bo'lmagan asinxron so'rovlar mavjud bo'lsa va faqat barchasi tugagandan keyingina UIni yangilash kerak bo'lsa, DispatchGroup ideal echimdir.16 Vazifa boshlanishidan oldin .enter() va tarmoq javobi kelganida .leave() chaqiriladi. Eng katta xavf shundaki, xato (error) yuz bergan blokda ham .leave() qo'yilishi shart, aks holda .notify(queue:.main) bloki umuman ishlamaydi va foydalanuvchi abadiy yuklanish (loading) ekranida qolib ketadi.16

37\. DispatchSemaphore arxitekturasi va uning xatarlari

DispatchSemaphore ma'lum bir resursga bir vaqtda kirish huquqini qat'iy cheklaydi (masalan, bir vaqtning o'zida maksimal 3 ta surat yuklanishi uchun).16 .wait() orqali ijozat so'raladi va u hisoblagichni kamaytiradi (0 bo'lsa kutib turadi). Ish bitgach .signal() orqali bo'shatiladi. Xatarli tomoni: .wait() funksiyasi ishlatilgan amaldagi thread'ni to'g'ridan-to'g'ri qulflab, muzlatib qo'yadi. Agar uni Main Thread'da ishlatsangiz dastur osiladi.16

38\. DispatchBarrier va "O'quvchi-Yozuvchi" (Read-Write) muammosi

Parallel ravishda o'qish (Read) ishlari bir nechta thread'da amalga oshirilishi mumkin, lekin yozish (Write) sodir bo'layotgan bir necha millisoniya davomida o'qish ham, boshqa yozish ham butunlay to'xtab turishi (exclusive access) zarur. Concurrent queue'ga vazifa flags:.barrier bilan jo'natilsa, u o'zidan avval jo'natilgan barcha tasklar tugashini kutadi, so'ngra faqat o'zi qulf holatida ishlashni davom ettiradi, ishini tugatgach navbatni ochiq (concurrent) holatiga qaytaradi.16

39\. concurrentPerform qachon foyda beradi?

DispatchQueue.concurrentPerform for-loop siklining multithreading uchun moslashtirilgan, parallel versiyasidir.16 U berilgan siklni mavjud yadrolarga ko'ra bir necha parallel thread'larga taqsimlab juda tez ishlaydi, va barcha iteratsiyalar tugamaguncha chaqirilgan thread'ni bloklab turadi. Faqat rasmlarni filtrdan o'tkazish kabi CPU-intensive masalalar uchun tavsiya etiladi.

40\. NSOperationQueue arxitekturasining GCD dan afzalligi nimada?

OperationQueue va Operation — bular bevosita GCD ustiga qurilgan, Ob'ektga-Yo'naltirilgan Dasturlash (OOP) tamoyillariga moslangan yuqori darajadagi abstraction qatlamidir.32 GCD da vazifalar guruhlansa-da, A vazifa tugamasdan B va C vazifalar umuman ish boshlamasin, degan murakkab qaramlik qoidalarini (dependencies) o'rnatish noqulay. Operation sinfi orqali addDependency metodini chaqirib har qanday murakkab zanjir va graflarni tuzish mumkin.32

Xotira Boshqaruvi (ARC, RAM, CPU Optimallashtirish)

iOS xotirasi (RAM) qat'iy chegaralangan. OOM termination (tizim tomonidan o'ldirilish) muammolari ustida izlanish Middle-Senior darajadagi eng ommabop suhbat mavzusidir.

41\. ARC (Automatic Reference Counting) qanday mexanizm va Retain Cycle nima?

ARC \- bu Swift kompilyatorining o'zida amalga oshiriladigan mexanizm bo'lib, har bir reference type (Class) ob'ekti xotirada nechta joydan kuchli bog'liqlik bilan (strong reference) ushlab turilganini hisoblab boradi.15 Bu hisob-kitob kompilatsiya vaqtidayoq kiritiladi, ya'ni run-time vaqtida Garbage Collector kabi tizimni sekinlashtirmaydi. Qachonki ob'ekt count nolga tushsa, uning xotirasi ozod qilinadi (deinit chaqiriladi). Retain Cycle (Bog'liqlik zanjiri) esa A ob'ekt B ob'ektni kuchli bog'liqlik bilan ushlab turganda, B ob'ekt ham A ob'ektni ko'rsatib, ikkisi bir-birini abadiy xotirada ushlab qolishi natijasida kelib chiqadigan Memory Leak (xotira oqishi) holatidir.15

42\. Strong, Weak va Unowned reference'lar o'rtasidagi tafovutlar

Ushbu uchta kalit so'z Retain Cycle'ni sindirish (break) uchun ishlatiladi 15:

• Strong: (Standart qiymat) Reference count ni 1 ga oshiradi.
• Weak: Reference count ni oshirmaydi. Qachonki ob'ekt xotiradan tozalansa, weak qilib e'lon qilingan o'zgaruvchi avtomatik ravishda nil qiymatini qabul qiladi. Shu xususiyati tufayli u doimo Optional turda (masalan, weak var delegate: MyDelegate?) bo'lishi shart.15
• Unowned: Bu ham count ni oshirmaydi, lekin xotiradan o'chirilsa ham pointer (ko'rsatkich) o'zgarishsiz qoladi.15 Agar ob'ekt dealloc bo'lganidan keyin unowned o'zgaruvchiga murojaat qilsangiz, Fatal Error yuz beradi.

43\. Closure (Yopilishlar) ichida xotira oqishi sabablari va ularning yechimi

Closure'lar o'zlari e'lon qilingan muhitdagi o'zgaruvchi va ob'ektlarni "tutib oladi" (capture).34 Agar siz class ichidagi closure'dan self.doSomething() ni chaqirsangiz, closure butun boshli self ni kuchli reference orqali egallaydi.35 Buni to'g'rilash uchun muhandislar har doim Capture List (Tutib olish ro'yxati) dan foydalanadi: \[weak self\] yozish orqali closure faqat zaif reference oladi.34 SwiftUI da struct ishlanganligi uchun View'lar doirasida bunday muammolar kam uchraydi, biroq class'ga asoslangan ViewModel'larda callback'lar asorati hamon jiddiy xavfdir.

44\. Escaping va Non-Escaping closure arxitekturasi

Standart (non-escaping) closure o'zi kiritilgan funksiyaning ishi tugashi bilanoq xotiradan tozalanadi.36 Unda retain cycle xavfi deyarli yo'q. @escaping tirkamasi esa funksiya yopilishi u yuborilgan kontekstdan "qochib ketishini", ya'ni funksiya o'z ishini tugatgandan so'ng uzoqroq vaqt o'tib (masalan asinxron javob kelgach) chaqirilishi mumkinligini bildiradi.34 Shuning uchun kompilyator u yerda albatta self ishtirokini va to'g'ri xotira boshqaruvini talab qiladi.

45\. Autoreleasepool mexanizmi nima va u qachon kerak?

Har bir User Interface munosabatlar aylanmasi (RunLoop) so'ngida iOS xotirani o'zi hosil qilgan vaqtinchalik ob'ektlardan tozalash maqsadida Autoreleasepool ni bo'shatadi.15 Lekin juda katta massivlar yoki tsikllar ichida masalan minglab rasmlarni filtrlasangiz, RunLoop hali tugamasdan xotira keskin ko'payib (Memory spike), ilova yopilib ketadi.15 Shu o'rinda dasturchi tsikl ichida autoreleasepool { } blokini ochib, yirik operatsiyalarni aynan shu blokda saqlashi shart. Bu blok o'z ichidagi hamma narsani darhol o'chiradi.

46\. Jetsam Events va OOM (Out of Memory) jarayonlari qanday kechadi?

Mac kompyuterlaridan farqli o'laroq, iOS mobil tizimida RAM cheklangan va "Swap" xotira (Diskni RAM sifatida ishlatish) mavjud emas. Agar sizning ilovangiz keragidan ortiq xotira so'rasa, dastlab AppDelegate yoki NotificationCenter orqali didReceiveMemoryWarning ogohlantirishi yuboriladi.15 Agar muhandis bu signaldan keyin ham rasmlarni keshdan tozalamasa, iOS kernel'i darajasidagi eng qattiqqo'l nazoratchi — Jetsam ishga tushadi.15 U operativ xotirani eng tez to'ldirayotgan jarayonni, ko'pincha sizning dasturingizni, hech bir ogohlantirishsiz o'ldiradi (OOM Termination).38

47\. iOS ilovalari uchun taxminiy RAM limitlari qanday taqsimlanadi?

Apple rasmiy hujjatlarda aniq raqamlarni bermaydi, sababi limitlar qurilma modeli va OS holatiga qarab dinamik o'zgaradi. Biroq tahlillar shuni ko'rsatadiki 15:

• Eski qurilmalarda limit taxminan jami RAMning 50% ni (1 \- 1.5 GB).
• iPhone 15 Pro kabi qurilmalarda Foreground (ekranda ishlayotgan) ilovalar uchun 3 GB atrofida.
• Lekin Notification Service, Widget yoki Background Task'lar uchun limit juda qattiq, bor-yo'g'i \~180MB yoki undan kam bo'ladi. Xotirani ko'p iste'mol qiluvchi API'larni fonda ishlatish ko'pincha fatal crash'lar bilan yakunlanadi.15

48\. Image Downsampling nima uchun CoreGraphics orqali qilinishi shart?

Rasm fayli diskda 3MB ni egallashi uning xotirada ham shuncha joy oladi degani emas. Masalan 4000x3000 pikselli suratni UIImage(named:) yoki to'g'ridan-to'g'ri SwiftUI Image orqali yuklasangiz, iOS tizimi uni ko'rsatish uchun uning har bir pikselini ochadi. Formulaga ko'ra, 4000 \ 3000 \ 4 bytes (RGBA) \= \~48 MB RAM joy band bo'ladi.15 Buni optimallashtirish uchun surat to'liq dekod qilinmasidan oldin CGImageSourceCreateThumbnailAtIndex qismi orqali suratning o'lchami kichraytiriladi (Downsampling).15 Bu texnika RAM spikelarini keskin qisqartiradi.

49\. Xcode Instruments yordamida Memory Leak qanday qidiriladi?

Instruments tarkibidagi "Allocations" va "Leaks" shablonlari eng asosiy tahlil vositasidir.15 Shuningdek, Xcode'ning "Debug Memory Graph" xususiyati (pastki paneldagi uchta nuqtali ikonka) ajoyib vosita.36 U ilovani pauzaga tushirib, barcha ob'ektlarning vizual daraxtini chizadi. Qalin chiziqlar (strong references) ga qarab, qaysi ob'ektlarni o'chirish imkonsiz bo'lib qolganligini aniqlash mumkin.15

50\. Nima uchun Delegate pattern iOS tizimida doim "weak" qilinadi?

Delegate pattern iOS'da tarkibiy qism hisoblanadi. Ota View Controller bola UI komponentini o'ziga xossa qilib yaratganda uni strong qilib ushlaydi. Bola komponent o'zida yuz bergan o'zgarishlarni otaga xabar berishi uchun o'zidagi delegate o'zgaruvchisiga otani ko'rsatib qo'yadi. Agar ushbu delegate ham strong (yoki oddiygina e'lon qilingan) bo'lsa, ikki tomon bir-birini hech qachon xotiradan qo'yib yubormaydi.15 Shu sabab protokol doim AnyObject bo'lishi va property oldidan weak yozilishi temir qoidadir.

Core Logic, Arxitektura va App Performance

Dastur tizimi arxitekturasi va mantiqiy kod yozish strategiyalari dasturning yashovchanligini belgilaydi. Senior muhandis ushbu makro muammolarni mukammal bilishi kerak.

51\. Protocol-Oriented Programming (POP) paradiqmasining OOP dan afzalligi

Obyektga yo'naltirilgan dasturlash (OOP) asosan vorislikka (inheritance) asoslanadi: bolalar ota sinfidan metodlarni meros oladi. Vaqt o'tishi bilan bu juda qalin va mantiqan bir-biriga mos kelmaydigan, o'zgartirish qiyin bo'lgan ierarxiyani keltirib chiqaradi.39 POP esa kompozitsiyaga (composition) suyanadi. Funksionalliklar protokollarga bo'linadi va Protocol Extension'lar yordamida standart funksionallikka ega bo'ladi.39 POP orqali biz Swift'dagi Struct'larga go'yoki meros xususiyatini ulasha olamiz, aslini olganda Struct boshqa Struct'dan meros ololmaydi. SwiftUI'dagi barcha View'lar ushbu POP tamoyiliga qurilgan.3

52\. MVVM va Clean Architecture (VIPER) taqqoslanishi

• MVVM: Model \- View \- ViewModel. Model faqat data, View faqat qiyofa bo'lib, barcha qaramliklar va vizual logikalar ViewModel'da yig'iladi.41 Biroq yirik ilovalarda API qidiruvlari, state management va tranzaksiyalar yig'ilganda u Massive ViewModel muammosiga olib keladi.41
• VIPER: View, Interactor, Presenter, Entity, Router. Mas'uliyatni juda qat'iy ajratadi.41 Uni test qilish oson, lekin har bir oddiy ekran yaratish uchun 5 ta alohida fayl yaratish talab qilinishi boilerplate kodlar miqdorini oshirib yuboradi.

53\. Dependency Injection (DI) va uning Unit Testing'dagi qadri

Dependency Injection biron bir ob'ekt (masalan NetworkManager) o'ziga kerak bo'lgan boshqa xizmatlarni (Database) o'z ichida yaratib olmasdan, ularni tashqaridan (Init, Property yoki Method orqali) qabul qilish jarayonidir.42 Bu test jarayonidagi (Unit Testing) eng katta quroldir. Tasavvur qiling, ilovangiz real vaqtda haqiqiy kredit kartalaridan pul yechadi. Test yozish paytida DI orqali haqiqiy tarmoq o'rniga mock (soxta, pul yechmaydigan faqat javob qaytaradigan) fayllarni yuboradigan soxta klassni berib yuboramiz. Shunday qilib kod o'zgarishsiz, mutlaqo izolyatsiyalangan holda test qilinadi.43

54\. SOLID prinsiplari Swift va iOS kontekstida

• Single Responsibility (Yagona Mas'uliyat): Sinfning o'zgarishi uchun faqat bitta sabab bo'lishi kerak. Parsing klassi faqat parse qilsin, internetdan yuklamasin.44
• Open/Closed (Ochiq-Yopiq): Kod qo'shilishga ochiq, lekin o'zgartirishga yopiq bo'lishi kerak (Extensionlar yoki Protokollar yordamida).
• Liskov Substitution (Liskov o'rnini bosish): Agar protokol parametr kutsa, unga har qanday o'sha protokolni qo'llagan boshqa sinfni berish imkoni bo'lishi kerak.
• Interface Segregation (Interfeyslarni ajratish): 10 ta metodga ega bitta yirik protokol yozgandan ko'ra, 2 tadan metodga ega 5 ta mayda protokol yozish yaxshi. Shunda sinflar faqat o'ziga kerak xossani amalga oshiradi.
• Dependency Inversion (Qaramliklarni teskari aylantirish): Yuqori darajadagi modullar past darajadagi modullarga qaram bo'lmasligi kerak, har ikkisi abstraksiyaga (Protokolga) qaram bo'lishi kerak.45

55\. App Launch Optimization (Ilova yuklanish vaqtini tezlashtirish) sirlari

Ilovaning ochilishi ikki faza: Pre-main (dyld) va Post-main (didFinishLaunching) fazalaridan iborat.46 Sekinlashuvning asosiy ildizi Pre-main bosqichida juda ko'p "Dynamic Frameworks" larning bir-biriga bog'lanishi (linking) va initsializatsiyasiga borib taqaladi. Optimization: framework'larni "Static Libraries" ko'rinishiga o'tkazish tavsiya qilinadi.47 Post-main bosqichida esa og'ir konfiguratsiyalarni Main Thread'da qoldirmay, DispatchQueue.global().async ga o'tkazish kerak.20

56\. FPS (Frames Per Second) pasayishi (Frame Drop / Hitch) nega sodir bo'ladi?

iOS ekranlari ravon ko'rinishi uchun sekundiga kamida 60 kadr chizishi kerak. Bu 1 soniyani 60 ga bo'lsangiz, bitta kadrni tayyorlash uchun protsessorda jami 16.67 millisoniya (ms) vaqt borligini anglatadi.15 Agar Asosiy Thread'da katta hajmli JSON parsing, og'ir Auto Layout hisob-kitoblari yoki katta rasmlarni o'qish jarayoni boshlanib, u 30-40 ms vaqt olsa, tizim o'z vaqtida kadrni ko'rsata olmaydi va uni tushirib qoldiradi. Bu foydalanuvchiga ekraning qotishi yoki "skroll uzilishi" bo'lib ko'rinadi.15 Optimallashtirish yo'llari: background hisoblashlarga o'tish va UI murakkabligini pasaytirish.49

57\. iOS App Binary hajmini kamaytirish (Size Optimization) chora-tadbirlari

Ilovalar hajmi foydalanuvchilarning ularni yuklab olish istagiga bevosita ta'sir qiladi. Optimizatsiya strategiyalari 49:

1. Asset Catalog va App Thinning: Barcha rasmlar Assets ichida tursin. Apple serverlari ilovani yuklayotganda, faqat o'sha telefon modeliga mos keladigan @2x yoki @3x rasm formatini jo'natadi.49
2. Dead Code Stripping: Ishlatilmayotgan eskirgan kod bloklarini va arxitektura turlarini o'chirish.49
3. Formatlar: .png o'rniga vektor (SVG, PDF) yoki HEIC, WebP formatlaridan foydalanish hajmni keskin tejaydi.

58\. Singleton naqshining "Anti-pattern" deb atalishiga texnik sabablar

shared yoki default instansiyasi ilovaning istalgan nuqtasidan ochiq bo'lgani uchun kodning tarkibiy bo'laklari bir-biriga chambarchas yopishib qoladi (tight coupling).44 Masalan, biron modul o'zgarishi barcha boshqa modullarga ko'rinmas ta'sir o'tkazadi (hidden dependencies). Oqibatda Unit test yozish va ularni izolyatsiyada tekshirish g'oyat qiyinlashadi. Bitta test buzgan state o'zidan keyin kelgan ikkinchi testning natijasini ham o'zgartiradi. Global ob'ekt kerak bo'lganda DI yordamida uzatish orqali bu xavf chetlab o'tiladi.

59\. App State Management strategiyalari (Redux, TCA vs MVVM)

MVVM har bir ekran uchun o'z state'ini saqlaydi.51 Biroq ekranlar o'rtasida katta miqdordagi ma'lumot almashinilganda, ma'lumotlar ziddiyati boshlanadi. The Composable Architecture (TCA) yoki Redux yondashuvlarida butun ilova bo'yicha Yagona State (Single Source of Truth) modeli qo'llaniladi. Barcha View'lar faqat o'ziga tegishli state qismini o'qiydi va o'zgartirish qilish uchun yagona kanal (Action) larni yuboradi.51 Bu arxitektura debugging va state time-travel xususiyatlarini eng yuqori nuqtaga olib chiqadi.51

60\. zxxx

Katta monolit kod bazasini SPM (Swift Package Manager) yoki Tuist orqali kichikroq, mutlaqo mustaqil modullarga (Core, Network, UIComponents, Features) bo'lish yondashuvidir.41 Bu eng avvalo kompilyatsiya tezligida inqilob yasaydi. Agar muhandis Login modulida kod yozayotgan bo'lsa, xarita yoki To'lovlar moduli qayta kompilyatsiya qilinmaydi (keshdan o'qiladi). Shuningdek jamoaning har xil qismlari bir-biriga xalaqit qilmay ishlay oladi va Shared modullar boshqa yangi ilovalarga oson ko'chiriladi.51 Bunday miqyos (scale) tizimlarini ko'ra olish Senior iOS dasturchining eng asosiy fazilatidir.44

Works cited

1. shobhakartiwari/SwiftUI-Interview-Questions \- GitHub, accessed February 20, 2026, https://github.com/shobhakartiwari/SwiftUI-Interview-Questions
2. Top Senior iOS Developer Interview Questions 2025: SwiftUI (Part 1\) | by Ahil NS | Medium, accessed February 20, 2026, https://medium.com/@eahilendran/ios-developer-interview-question-2025-part-1-swift-20d2517f1e32
3. Top 15 SwiftUI Interview Questions and Answers, accessed February 20, 2026, https://skillora.ai/blog/swiftui-interview-questions-and-answers
4. Behind the scenes of UI: Part 2 \- SwiftUI \- Vitaly Batrakov, accessed February 20, 2026, https://vbat.dev/behind-the-scenes-of-ui-part-2-swiftui
5. A Day in the Life of a SwiftUI View \- Chris Eidhof, accessed February 20, 2026, https://chris.eidhof.nl/presentations/day-in-the-life/
6. SwiftUI Interview Questions & Answers | by Shashidhar Jagatap \- Medium, accessed February 20, 2026, https://medium.com/@shashidj206/this-insightful-medium-article-compiles-a-comprehensive-array-of-swiftui-interview-questions-a3fad8764d9a
7. How the SwiftUI View Lifecycle and Identity work \- DoorDash, accessed February 20, 2026, https://careersatdoordash.com/blog/how-the-swiftui-view-lifecycle-and-identity-work/
8. Mastering SwiftUI Performance \- Mazvydas Katinas \- Medium, accessed February 20, 2026, https://yourcoachmaz.medium.com/mastering-swiftui-performance-054d289c8908
9. SwiftUI equatable view optimization \- Stack Overflow, accessed February 20, 2026, https://stackoverflow.com/questions/65041701/swiftui-equatable-view-optimization
10. How to Avoid Repeating SwiftUI View Updates \- Fatbobman's Blog, accessed February 20, 2026, https://fatbobman.com/en/posts/avoid\_repeated\_calculations\_of\_swiftui\_views/
11. Debugging SwiftUI Views Using Self.\_printChanges \- YouTube, accessed February 20, 2026, https://www.youtube.com/watch?v=OTtEC-wHgtY
12. Understanding and improving SwiftUI performance | Apple Developer Documentation, accessed February 20, 2026, https://developer.apple.com/documentation/Xcode/understanding-and-improving-swiftui-performance
13. SwiftUI Performance Profiling with Instruments (Practical Guide) \- DEV Community, accessed February 20, 2026, https://dev.to/sebastienlato/swiftui-performance-profiling-with-instruments-practical-guide-389b
14. 3 Debug Tricks for SwiftUI in 2025\! \- YouTube, accessed February 20, 2026, https://www.youtube.com/watch?v=rFohlNeNAd0
15. Mastering iOS Performance Monitoring: FPS and Memory Usage Interview Questions Answered | by Jeffery Alexandro Henry | Feb, 2026 | Medium, accessed February 20, 2026, https://medium.com/@alaxhenry0121/mastering-ios-performance-monitoring-fps-and-memory-usage-interview-questions-answered-83ae135fd48f
16. DispatchQueue in iOS — The Complete Interview Q\&A Guide (Swift, GCD & Concurrency), accessed February 20, 2026, https://medium.com/@aksingh20feb/dispatchqueue-in-ios-the-complete-interview-q-a-guide-swift-gcd-concurrency-1817e59b51e2
17. GCD vs async await. GCD (Grand Central Dispatch) | by Yunusbek Sadullaev \- Medium, accessed February 20, 2026, https://medium.com/@iam.developer.yu/gcd-vs-async-await-23390c088504
18. When execute GCD's async task, Is executing like Async/Await or not? \- Swift Forums, accessed February 20, 2026, https://forums.swift.org/t/when-execute-gcds-async-task-is-executing-like-async-await-or-not/62970
19. Global actors vs. Task vs. MainActor \- Swift Forums, accessed February 20, 2026, https://forums.swift.org/t/global-actors-vs-task-vs-mainactor/57292
20. 125 iOS Swift Interview Questions in 2026 \- Curotec, accessed February 20, 2026, https://www.curotec.com/interview-questions/125-ios-swift-interview-questions/
21. iOS Interview Questions You Should Know — Part 3 Concurrency | by Harpreet Kaur, accessed February 20, 2026, https://medium.com/@HarpreetVKaur/ios-interview-questions-you-should-know-part-3-04f888bf3498
22. Conquer Data Races with Swift Actors \- Alex Dremov, accessed February 20, 2026, https://alexdremov.me/conquer-data-races-with-swift-actors/
23. Actor reentrancy in Swift explained \- Donny Wals, accessed February 20, 2026, https://www.donnywals.com/actor-reentrancy-in-swift-explained/
24. Question on Swift Concurrency with Actors \- Reddit, accessed February 20, 2026, https://www.reddit.com/r/swift/comments/1b4628u/question\_on\_swift\_concurrency\_with\_actors/
25. Actor Races \- Discussion \- Swift Forums, accessed February 20, 2026, https://forums.swift.org/t/actor-races/60439
26. MainActor usage in Swift explained to dispatch to the main thread \- SwiftLee, accessed February 20, 2026, https://www.avanderlee.com/swift/mainactor-dispatch-main-thread/
27. @MainActor and Global Actors in Swift \- Andy Ibanez, accessed February 20, 2026, https://www.andyibanez.com/posts/mainactor-and-global-actors-in-swift/
28. Operation and Grand Central Dispatch interview questions, accessed February 20, 2026, https://charlieinden.github.io/ios-interviews/2018-10-23\_Operation-and-Grand-Central-Dispatch-interview-questions-694da9a069fb.html
29. A Deep Dive Into Swift's DispatchWorkItem | by Kiran \- Better Programming, accessed February 20, 2026, https://betterprogramming.pub/a-deep-dive-into-dispatchworkitem-274548357dea
30. Mastering Concurrency in iOS \- Part 3 (Dispatch Group, Dispatch Work Item) \- YouTube, accessed February 20, 2026, https://www.youtube.com/watch?v=SGEWlYB6ZM0
31. 99 Swift interview questions to hire top developers \- Adaface, accessed February 20, 2026, https://www.adaface.com/blog/swift-interview-questions/
32. 15 iOS Interview Questions for Hiring iOS Engineers \- Terminal.io, accessed February 20, 2026, https://www.terminal.io/blog/15-ios-interview-questions-for-hiring-ios-engineers
33. iOS Interview Prep 1 — Memory management \- DEV Community, accessed February 20, 2026, https://dev.to/boredavo/ios-interview-prep-1-memory-management-3ag7
34. Swift Memory Management: Avoiding Memory Leaks in Closure Blocks (A Journey of My Coding Life) | by Yannis Alexiou | Medium, accessed February 20, 2026, https://medium.com/@yannisalexiou/swift-memory-management-avoiding-memory-leaks-in-closure-blocks-a-journey-of-my-coding-life-f637ce9773dc
35. SwiftUI Memory Management & Retain Cycle Pitfalls (Production Guide) \- DEV Community, accessed February 20, 2026, https://dev.to/sebastienlato/swiftui-memory-management-retain-cycle-pitfalls-production-guide-2kii
36. Breaking Free from Retain Cycles: Managing Escaping Closures in Swift | Swiftfy \- Medium, accessed February 20, 2026, https://medium.com/swiftfy/breaking-free-from-retain-cycles-managing-escaping-closures-in-swift-d73690e76c19
37. Understanding Swift Closures \- Vitaly Batrakov, accessed February 20, 2026, https://vbat.dev/understanding-swift-closures
38. Identifying high-memory use with jetsam event reports | Apple Developer Documentation, accessed February 20, 2026, https://developer.apple.com/documentation/xcode/identifying-high-memory-use-with-jetsam-event-reports
39. OOP vs POP in Swift — iOS Interview Question | by Tanishq Arora \- Medium, accessed February 20, 2026, https://medium.com/@ios-interview/oop-vs-pop-in-swift-ios-interview-question-4f50d4cf7df7
40. IOS INTERVIEW QUESTIONS DAY 103\. Protocol-Oriented Programming (POP)… \- Pubudu Dilshan, accessed February 20, 2026, https://pubududilshan.medium.com/ios-interview-questions-day-103-a0771a0f9aab
41. Here's a deep-dive iOS architecture interview question set, ideal for mid-to-senior iOS developers… \- Medium, accessed February 20, 2026, https://medium.com/@anujiosdeveloper/heres-a-deep-dive-ios-architecture-interview-question-set-ideal-for-mid-to-senior-ios-developers-df24eabf365e
42. Top 5 Dependency Injection iOS Interview Questions \- Swift Anytime, accessed February 20, 2026, https://www.swiftanytime.com/blog/ios-interview-questions-dependency-injection
43. IOS INTERVIEW QUESTIONS DAY 70\. Dependency Injection | by Pubudu Dilshan | Medium, accessed February 20, 2026, https://pubududilshan.medium.com/ios-interview-questions-day-70-9622a0bbf2d0
44. iOS Interview Questions for Senior Developers in 2020, accessed February 20, 2026, https://iosinterviewguide.com/ios-interview-questions-for-senior-developers-in-2020
45. iOS interview questions you feel are common? : r/iOSProgramming \- Reddit, accessed February 20, 2026, https://www.reddit.com/r/iOSProgramming/comments/wpwrxx/ios\_interview\_questions\_you\_feel\_are\_common/
46. Optimizing App Launch \- WWDC19 \- Videos \- Apple Developer, accessed February 20, 2026, https://developer.apple.com/videos/play/wwdc2019/423/
47. Testing your app launch time (iOS) | by Morgan Collino \- Level Up Coding \- Gitconnected, accessed February 20, 2026, https://levelup.gitconnected.com/testing-your-app-launch-time-ios-e3d1471dda54
48. How We Reduced Our iOS App Launch Time by 60% \- DoorDash, accessed February 20, 2026, https://careersatdoordash.com/blog/how-we-reduced-our-ios-app-launch-time-by-60/
49. Top iOS Developer Interview Questions with Answer | by Anand Gaur \- Medium, accessed February 20, 2026, https://medium.com/@anandgaur2207/top-ios-developer-interview-questions-with-answer-2c4372f93889
50. iOS Developer Interview Questions: Prepare For Your Interview \- Resume Worded, accessed February 20, 2026, https://resumeworded.com/interview-questions/ios-developer
51. Here are more deep-dive iOS architecture interview questions with real-world scenarios, follow-up… \- Medium, accessed February 20, 2026, https://medium.com/@anujiosdeveloper/here-are-more-deep-dive-ios-architecture-interview-questions-with-real-world-scenarios-follow-up-bff2f7f4c3ce