7 वर्षों बाद SwiftUI
अपनी शुरुआत के सात साल बाद, Apple का SwiftUI framework कई डेवलपर्स को साधारण, declarative interfaces के लिए शक्तिशाली लेकिन जटिल, performance-sensitive apps के लिए अविश्वसनीय और कमज़ोर लगता है, खासकर UIKit/AppKit और पुराने Cocoa patterns की तुलना में। टिप्पणियों में opaque state management, layout fragility, missing या unstable APIs, और Swift language features के साथ कड़ी coupling को मुख्य समस्याएँ बताया गया है; जबकि एक छोटा समूह नवीनतम OS versions पर अच्छे अनुभव साझा करता है और कहता है कि इसकी trade-offs स्वीकार करने पर यह “good enough” है। बहस Apple की software दिशा, सालाना breaking changes की लागत, और क्या Flutter, Kotlin Multiplatform, या classic Objective-C-based stacks अब अधिक sustainable रास्ता देते हैं, इस पर भी फैल जाती है।
SwiftUI का मूल्य प्रस्ताव और वास्तविकता
- कई लोग SwiftUI को साधारण, “सरफेस-लेवल” UIs के लिए शानदार मानते हैं: सूचियाँ, फ़ॉर्म, बुनियादी CRUD, सरल एडमिन टूल्स, और विज़ुअल इफ़ेक्ट्स (blur, masks, Metal-backed views)।
- जटिल ऐप्स के लिए (भारी सूचियाँ, कस्टम लेआउट, जटिल नेविगेशन, परिष्कृत macOS windowing, सटीक animations), लोग performance issues, layout fragility, और UIKit/AppKit तक कई “escape hatches” की शिकायत करते हैं।
- कई इसे “newbie trap” कहते हैं: आसान demos, लेकिन असली दुनिया का काम कठिन। बड़े प्रोजेक्ट्स में bugs और अजीब व्यवहार अक्सर देर से सामने आते हैं।
State, declarative UI, और architecture
- declarative-reactive बनाम imperative पर बड़ी बहस:
- समर्थक: state-as-source-of-truth और declarative views update-logic bugs कम करते हैं और सामान्य मामलों को आसान बनाते हैं।
- आलोचक: SwiftUI की reactivity अपारदर्शी है; view update timing को समझना कठिन है;
@State/@Binding/@ObservableऔरGeometryReaderजैसे tools “magic” footguns माने जाते हैं।
- लंबा subthread क्लासिक MVC पर फिर से आता है: कुछ लोग कहते हैं कि “proper” MVC पहले से ही भारी reactive machinery के बिना अधिकांश state-sync समस्याएँ हल कर देता है; अन्य कहते हैं कि MVC के अपने व्यावहारिक मुद्दे हैं (event storms, batching updates, layout performance)।
APIs, stability, और tooling
- बार-बार शिकायतें:
- API churn (जैसे evolving navigation APIs, state systems), OS-version conditionals, और iOS versions के बीच व्यवहार के अंतर।
- खराब या बिखरा हुआ documentation; WWDC videos और third-party blogs पर निर्भरता।
- कमजोर debugging और profiling support (view hierarchy inspection, re-renders को समझना), हालांकि कुछ लोग नई Instruments support का उल्लेख करते हैं।
- कुछ का तर्क है कि यदि आप पुराने OS support छोड़ सकते हैं, तो iOS 26–27 से SwiftUI “बहुत अच्छा” है; जबकि अन्य कहते हैं कि मौजूदा versions में भी real apps में stutter और CPU-heavy व्यवहार बना रहता है।
Swift, UIKit/AppKit, और Apple संस्कृति
- Objective-C + Cocoa/AppKit/UIKit के लिए मजबूत nostalgia: इन्हें elegant, powerful, और जटिल native apps के लिए बेहतर माना जाता है; कुछ लोग Swift को अत्यधिक जटिल और Apple platforms के बाहर सीमित आकर्षण वाला मानते हैं।
- अन्य लोग कहते हैं कि Swift एक बड़ा सुधार है और अब उनकी primary language everywhere है; उन्हें AppKit/UIKit verbose और dated लगते हैं।
- कई लोग leadership और KPI-driven decisions को Swift/SwiftUI को एक दशक तक “half-baked” रूप में ship करने के लिए दोष देते हैं, और इसे शुरुआती NeXT/Cocoa era से तुलना करते हैं।
Alternatives और cross-platform चर्चा
- Flutter, Kotlin Multiplatform + Compose, Qt, React Native, WPF, MAUI, HTML/CSS/JS — सभी को alternatives के रूप में चर्चा में लाया गया, जिनमें अलग-अलग trade-offs हैं।
- कुछ लोग अब SwiftUI की बजाय UIKit + AI assistants को पसंद करते हैं, उनका तर्क है कि AI SwiftUI के “easy layout” advantage को कम कर देता है।
- आम सहमति: कोई एक “सही तरीका” नहीं है; tool choice ऐप की जटिलता, target platforms, और SwiftUI की quirks को सहने की क्षमता पर निर्भर करती है।