Shopify React Native से वापस Swift और Kotlin की ओर जा रहा है
Shopify अपने mobile apps को React Native से वापस पूरी तरह native Swift और Kotlin में लिख रहा है, यह तर्क देते हुए कि आधुनिक AI coding agents ने दो codebases बनाए रखने की ऐतिहासिक लागत का बड़ा हिस्सा घटा दिया है। Commenters इसे एक बड़े बदलाव का हिस्सा मानते हैं: अगर LLMs दोहराए जाने वाले cross-platform काम संभाल सकते हैं, तो बड़ी companies native performance, tighter platform integration, और कम framework overhead को प्राथमिकता दे सकती हैं, भले ही एक साझा stack का लाभ खो जाए। अन्य लोग चेतावनी देते हैं कि parity, testing, और platforms के बीच long‑term maintenance अब भी कठिन समस्याएँ हैं, और छोटी teams के लिए React Native, Flutter, या web-based approaches की economics अभी भी अधिक आकर्षक हो सकती हैं.
Shopify के कदम के पीछे मानी जा रही वजह
- कई लोगों को लगता है कि यह बदलाव मुख्यतः React Native के “tax” से निकलने के लिए है: दर्दनाक upgrades, dependency churn, और upstream framework instability।
- कुछ अन्य लोगों का तर्क है कि असली कारण आंतरिक पसंद और politics है, न कि सिर्फ AI या objective cost।
- कई लोगों ने नोट किया कि Shopify पहले ही एक बड़े RN refactor (“New Architecture”) में धकेला जा रहा था, इसलिए stack पर दोबारा विचार करना समयोचित था।
AI/LLMs और native की economics
- व्यापक सहमति है कि coding agents native apps बनाने और port करने की लागत को बहुत कम कर देते हैं; कई commenters ने छोटे–मध्यम apps के overnight या बहुत तेज़ RN → Swift/Kotlin ports की रिपोर्ट की।
- समर्थकों का कहना है कि “one RN app vs two native apps” अब एक गलत tradeoff है: AI दोनों को maintain कर सकती है, खासकर अगर specs और tests साझा हों।
- संदेह करने वाले जवाब देते हैं कि AI RN को भी सस्ता बना देता है; parity/maintenance cost वर्षों में अभी भी अस्पष्ट और अप्रमाणित है।
React Native, Flutter, और विकल्प
- RN को workable लेकिन fragile बताया गया है: frequent breaking changes, awkward upgrades, uneven library quality, और performance/UX penalties, खासकर Android पर।
- Flutter को praise (“still loving it”) और dismissal (“dead-end”) दोनों मिले, और कुछ लोगों ने कहा कि उसका Skia-based stack स्वाभाविक रूप से भारी है।
- Kotlin Multiplatform, Rust+UniFFI, और native .NET का उल्लेख core logic साझा करते हुए native UIs बनाए रखने के बेहतर तरीकों के रूप में किया गया।
App Store review, OTA, और deployment
- मौजूदा iOS review times पर कड़ा मतभेद है: कुछ लोग <24h बताते हैं, जबकि अन्य 2–7+ दिन और काफी variance की रिपोर्ट करते हैं।
- RN के over-the-air (OTA) updates को fast bugfixes और compliance-driven changes के लिए एक बड़ा practical advantage माना गया है; move के आलोचक चिंता जताते हैं कि Shopify यह खो रहा है।
Parity, complexity, और organizational cost
- कई commenters कहते हैं कि सबसे कठिन हिस्सा initial rewrite नहीं, बल्कि वर्षों तक iOS/Android behavior को aligned रखना है: experiments, analytics, accessibility, edge cases।
- Shared specifications और tests को आवश्यक माना गया है, लेकिन उनकी long‑term effectiveness “unclear” बताई गई; लोग hard numbers चाहते हैं (hours, defect rates, drift incidents, model spend)।
AI, quality, और security concerns
- कुछ लोग “agentic” development को अपनाते हैं और Swift/Kotlin output को मुश्किल से पढ़ते हैं, tests और अतिरिक्त model-based reviewers पर भरोसा करते हैं।
- अन्य चेतावनी देते हैं कि इससे unmaintainable “vibe-coded” native apps बन सकती हैं, जिनमें hidden bugs, security issues (secrets, OAuth, WebViews), और brittle code होता है जिसे इंसान सच में नहीं समझते।
बड़ा रुझान
- कई लोगों का अनुमान है कि बड़े, अच्छी तरह-funded orgs native की ओर वापस जाएँगे, जबकि छोटी teams और MVPs RN/Flutter/web पर टिके रहेंगे।
- कई लोग Electron और heavy cross-platform stacks से व्यापक swing-away की भविष्यवाणी करते हैं, क्योंकि code “cheap” होता जा रहा है लेकिन complexity और runtime bloat अभी भी महंगे हैं।