Apple टेक्स्ट एडिटर के सोलो डेवलपमेंट के 9 साल
एक solo developer की नौ साल की यात्रा, जिसमें उसने Objective‑C में एक minimalist Mac/iOS text editor बनाया, native Apple development और web या cross-platform stacks के बीच trade-offs पर व्यापक चर्चा को जन्म देती है। टिप्पणीकार Swift बनाम Objective‑C, SwiftUI की परिपक्वता, backwards compatibility, और dependency avoidance पर बहस करते हैं, साथ ही यह भी दिखाते हैं कि UI details, pricing experiments, और direct in-app support पर obsessive ध्यान छोटे, paid indie apps को Apple platforms पर viable बना सकता है। कुल मिलाकर, यह thread Apple की native frameworks में संभव stability और craftsmanship की तुलना web पर तेज़ iteration और व्यापक reach के आकर्षण से करती है।
नेटिव बनाम वेब और प्लेटफ़ॉर्म स्थिरता
- कई टिप्पणीकारों का तर्क है कि वेब रनटाइम बेहद स्थिर है और लगभग पूरी तरह backward compatible है; पुराने JS ऐप्स आमतौर पर चलते रहते हैं।
- इसके विपरीत, नेटिव Apple प्लेटफ़ॉर्म को नाज़ुक माना जाता है: OS अपडेट ऐप्स को तोड़ सकते हैं, शुरुआती दौर में Swift में ABI stability नहीं थी, और Apple कई APIs को backport नहीं करता।
- कुछ लोग यह भी नोट करते हैं कि framework churn Windows और वेब पर Apple की तुलना में ज़्यादा समस्या है, जहाँ AppKit/UIKit समय के साथ अपेक्षाकृत स्थिर रहे हैं।
Objective‑C बनाम Swift और टूलिंग
- Objective‑C पर टिके रहने के चुनाव को लेकर तीखी बहस है।
- ObjC के पक्ष में तर्क: पुराना कोड आज भी compile होता है, compile times तेज़ हैं, tooling/debugger अधिक predictable है, यह “low-level और hackable” है, और कम maintenance वाले products के लिए अच्छा है।
- Swift के पक्ष में तर्क: Swift परिपक्व हो गया है, बेहतर safety और expressiveness देता है, अब ABI-stable है, और Apple नए frameworks और यहाँ तक कि Foundation के कुछ हिस्से भी Swift में लिख रहा है।
- कुछ लोग एक smooth gradual migration strategy बताते हैं (एक ObjC ऐप में Swift modules/tests जोड़ना); दूसरों को Swift की धीमी compilation और खराब error messages पसंद नहीं हैं।
- ObjC के दीर्घकालिक भविष्य को लेकर असहमति है: कुछ इसे अंततः sidelined मानते हैं; अन्य सोचते हैं कि यह लंबे समय तक Apple OSes में गहराई से embedded रहेगा।
SwiftUI बनाम UIKit/AppKit
- SwiftUI के अनुभव मिश्रित से लेकर नकारात्मक तक हैं: frequent changes (जैसे Combine → Observation), navigation/state की खराब कहानी, previews में bugs, और बड़े lists के लिए performance cliffs की शिकायतें।
- कुछ लोग कहते हैं कि अगर आप इसके “happy path” में रहें तो SwiftUI बढ़िया है, और complex हिस्सों के लिए आप UIKit/AppKit पर जा सकते हैं, यहाँ तक कि classic views के अंदर SwiftUI embed भी कर सकते हैं।
- अन्य लोगों को लगता है कि गंभीर apps के लिए SwiftUI अभी भी UIKit/AppKit से बहुत पीछे है।
UX विवरण और Caret Animation
- smooth caret animation पर राय बंटी हुई है: कुछ इसे सुखद “buttery” मानते हैं, जबकि अन्य इसे discrete jumps की तुलना में distracting या imprecise मानते हैं।
- कई लोग ज़ोर देते हैं कि subtle, discoverable touches (“fringes”) attachment, trust, और craft का एहसास बनाते हैं, खासकर text editors में।
Business Model और Distribution
- शुरुआती “Pro features” popup और notification permission prompt को व्यापक रूप से बहुत aggressive माना गया; डेवलपर इन्हें देर से दिखाने की योजना बना रहा है।
- यूज़र्स एक बार के “lifetime” विकल्प की सराहना करते हैं और बिना nag के basic mode की माँग करते हैं।
- एक बड़ा thread corporate purchasing पर है: in-app purchases MDM/Apple Business Manager के साथ काम नहीं करते, इसलिए कंपनियों को एक paid, non-IAP SKU चाहिए।
- चर्चा के बाद, डेवलपर support के लिए एक अलग, unlisted, paid “for business” App Store version बनाता है।
Website, SEO, और Marketing
- लंबा technical write-up page design और clarity के लिए सराहा गया; यह Tailwind और custom visuals के साथ hand-built है।
- ultra-thin custom scrollbar को व्यापक रूप से unusable माना गया; डेवलपर इसे iteratively चौड़ा करता है और hover पर expand होने देता है।
- साइट का SEO-oriented blog (जैसे “Best writing apps…” जैसी listicles) कुछ readers को दूर करता है; अन्य लोग नोट करते हैं कि users हासिल करने का यह एक pragmatic तरीका है। सुझाव दिए जाते हैं कि “real” articles को अलग RSS feed में बाँटा जाए।
Indie Economics, Platform Choice, और Dependencies
- कई लोग ऐप की polish, performance, और zero-third-party-dependency approach की प्रशंसा करते हैं, और इसका श्रेय AppKit/UIKit की गहराई को देते हैं।
- कई लोग तर्क देते हैं कि Apple users quality indie apps के लिए अपेक्षाकृत भुगतान करने को तैयार रहते हैं, जबकि सामान्य Windows/Linux users ऐसा कम करते हैं।
- ऐप अभी एक full-time European salary से काफी कम कमाता है, इसलिए यह फिलहाल side project बना हुआ है, लेकिन revenue बढ़ रहा है।
- Lock-in बनाम reach पर बहस है: कुछ लोग उच्च गुणवत्ता और कम headaches के लिए एक platform पर ध्यान देना पसंद करते हैं; अन्य बड़े markets तक पहुँचने के लिए cross-platform stacks (Flutter, React Native, Qt, Delphi, आदि) का समर्थन करते हैं, भले ही इससे “native feel” और features की कीमत चुकानी पड़े।