नेटिव या क्रॉस-प्लेटफ़ॉर्म मोबाइल ऐप?

बुडापेस्ट की सॉफ़्टवेयर विकास कंपनी Mesterséges Intelligencia Központ Kft. के अनुसार, नेटिव ऐप तब चाहिए, जब ऐप डिवाइस का गहराई से उपयोग करे; दोनों प्लेटफ़ॉर्म पर एक जैसी सुविधाएँ हों, तो एक साझा कोडबेस का रखरखाव सरल है।

मुख्य बात: निर्णय सुविधाओं पर टिका है, चलन पर नहीं: ऐप को डिवाइस में कितनी गहराई तक जाना है, उसे कितना प्रदर्शन चाहिए, और सालों तक रखरखाव कौन करेगा। स्टोर में उपस्थिति और डिवाइस तक गहरी पहुँच ज़रूरी न हो, तो वेब ऐप (PWA) भी काफ़ी हो सकता है। जो भी रास्ता चुनें, बैकएंड, स्टोर नियम और नियमित ऑपरेटिंग सिस्टम अपडेट काम का बड़ा हिस्सा हैं।

नेटिव, क्रॉस-प्लेटफ़ॉर्म और वेब ऐप का क्या अर्थ है?

मोबाइल ऐप तीन तरह से बनता है: हर प्लेटफ़ॉर्म के लिए अलग, उसके अपने टूल से; एक साझा कोडबेस से, जो दोनों के लिए कंपाइल होता है; या वेब तकनीक से, ब्राउज़र में। तीनों से चलने वाला ऐप बनता है; अंतर पहुँच, रखरखाव और इसमें है कि ऐप किसके नियमों से अपडेट होता है।

नेटिव ऐप

नेटिव ऐप में iOS और Android संस्करण अलग बनते हैं, प्लेटफ़ॉर्म की अपनी भाषा और UI टूल से। iOS पर आज आमतौर पर Swift और SwiftUI: Apple के अनुसार SwiftUI घोषणात्मक सिंटैक्स से, Swift पर आधारित, Apple के सभी प्लेटफ़ॉर्म पर इंटरफ़ेस बनाने देता है (Apple: SwiftUI)। Android पर Kotlin और Jetpack Compose: Google इसे नेटिव UI के लिए Android का अनुशंसित आधुनिक टूलकिट कहता है (Android Developers: Jetpack Compose), और नया Android ऐप Kotlin से शुरू करने की सलाह देता है (Android Developers: Kotlin-first)। फ़ायदा: प्लेटफ़ॉर्म की हर नई क्षमता पहले दिन से सीधे उपलब्ध; नुक़सान: दो कोडबेस का विकास और रखरखाव।

क्रॉस-प्लेटफ़ॉर्म फ़्रेमवर्क

क्रॉस-प्लेटफ़ॉर्म फ़्रेमवर्क से iOS और Android ऐप एक साझा कोडबेस से बनते हैं। चार आम तरीक़े:

Flutter: Dart भाषा का फ़्रेमवर्क। दस्तावेज़ीकरण के अनुसार यह सिस्टम के तत्वों के बजाय हर UI तत्व ख़ुद लागू करता है और Impeller इंजन से रेंडर करता है; प्लेटफ़ॉर्म का अपना कोड प्लेटफ़ॉर्म चैनल से बुलाया जाता है (Flutter: Architectural overview)।
React Native: React और JavaScript पर आधारित; परियोजना के शब्दों में यह JavaScript में लिखा, पर नेटिव कोड से रेंडर होता है, क्योंकि इसके मूल घटक नेटिव UI घटकों से मैप होते हैं (React Native)। संस्करण 0.76 से New Architecture डिफ़ॉल्ट है, जो एसिंक्रोनस ब्रिज की जगह JavaScript Interface (JSI) लाता है (React Native: New Architecture)।
Kotlin Multiplatform: JetBrains की ओपन-सोर्स तकनीक, जो कोड को Android, iOS, डेस्कटॉप, वेब और सर्वर के बीच साझा करती है: सिर्फ़ व्यावसायिक तर्क, नेटिव UI के साथ, या Compose Multiplatform से UI भी (Kotlin: Kotlin Multiplatform)। Kotlin दस्तावेज़ीकरण के अनुसार Compose Multiplatform iOS पर भी Stable स्तर पर है (Kotlin: stability of supported platforms, 17 अक्टूबर 2026 को जाँचा गया)।
.NET MAUI: C# और XAML वाला Microsoft फ़्रेमवर्क, जो एक साझा कोडबेस से Android, iOS, macOS और Windows ऐप बनाता है; यह Xamarin.Forms का अगला रूप है। iOS और macOS ऐप के लिए Mac चाहिए (Microsoft Learn: What is .NET MAUI?)।

प्रोग्रेसिव वेब ऐप (PWA)

PWA ब्राउज़र में चलने वाला वेब ऐप है, जो होम स्क्रीन पर इंस्टॉल हो सकता है और क्रमिक संवर्धन (progressive enhancement) से ज़्यादा भरोसेमंद अनुभव देता है। web.dev के अनुसार प्लेटफ़ॉर्म ऐप क्षमताओं में, वेब ऐप पहुँच में सबसे मज़बूत हैं: एक कोडबेस हर किसी तक, हर डिवाइस पर पहुँचता है (web.dev: Progressive Web Apps)। iOS और iPadOS 16.4 से होम स्क्रीन पर रखा वेब ऐप भी पुश नोटिफ़िकेशन की अनुमति माँग सकता है (WebKit: Web Push for Web Apps)। अहम सीमा: App Store दिशानिर्देशों के खंड 4.2 के अनुसार ऐप को दोबारा पैक की गई वेबसाइट से ज़्यादा देना चाहिए, इसलिए सिर्फ़ ऐप में लपेटी वेबसाइट स्टोर में ले जाना उचित नहीं (Apple: App Store Review Guidelines)।

एक तालिका में तुलना

मानदंड	नेटिव (Swift, Kotlin)	क्रॉस-प्लेटफ़ॉर्म (Flutter, React Native, KMP, .NET MAUI)	PWA
प्रदर्शन	प्लेटफ़ॉर्म के टूल से सीधे अनुकूलित	गणना-भारी हिस्से नेटिव कोड में जा सकते हैं	ब्राउज़र और वेब तकनीक तय करती है
डिवाइस तक पहुँच	हर प्लेटफ़ॉर्म सुविधा, पहले दिन से	फ़्रेमवर्क या प्लगइन से; नई सुविधा बाद में या अतिरिक्त नेटिव कोड से	ब्राउज़र के समर्थित वेब इंटरफ़ेस तक सीमित
रूप और अनुभव	ठीक प्लेटफ़ॉर्म के अपने तत्व	Flutter में ख़ुद बनाए तत्व, React Native में नेटिव तत्व	वेबसाइट जैसा, ब्राउज़र पर निर्भर
कोड साझा करना	नहीं, दो अलग कोडबेस	तर्क और ज़्यादातर UI भी साझा	हर डिवाइस के लिए एक कोडबेस
टीम	iOS और Android विशेषज्ञता अलग	एक टीम, पर नेटिव परतों का ज्ञान भी चाहिए	वेब डेवलपर टीम
रखरखाव	दो कोडबेस नियमित प्लेटफ़ॉर्म बदलावों के साथ	एक कोडबेस, और फ़्रेमवर्क के अपने अपडेट	स्टोर रिलीज़ नहीं, ब्राउज़र बदलाव देखने होते हैं
ऐप का आकार	सिस्टम की अपनी लाइब्रेरी पर	फ़्रेमवर्क इंजन भी ऐप में जाता है	इंस्टॉलेशन पैकेज नहीं, ब्राउज़र कैश करता है
स्टोर में उपस्थिति	हाँ	हाँ	ज़रूरी नहीं; स्टोर के लिए पैक करने पर खंड 4.2 की सीमा लागू

Flutter दस्तावेज़ीकरण साफ़ कहता है: Flutter ऐप का पैकेज आत्मनिर्भर है, चलने का सारा कोड और संसाधन उसमें हैं, इसलिए आकार मुद्दा हो सकता है (Flutter: Measuring your app's size)। व्यवहार में यह अंतर कम ही निर्णायक है, पर पुराने डिवाइस या कमज़ोर कनेक्शन वाले उपयोगकर्ताओं के लिए जानना उचित है।

कौन-सा कब ठीक है?

नेटिव, अगर

ऐप डिवाइस का गहराई से उपयोग करता है: कैमरा, सेंसर, Bluetooth, बैकग्राउंड काम;
उसे ज़्यादा प्रदर्शन चाहिए, जैसे रियल-टाइम चित्र या ऑडियो प्रसंस्करण, जटिल एनिमेशन;
प्लेटफ़ॉर्म की नवीनतम क्षमताएँ तुरंत इस्तेमाल करनी हैं;
ऐप सिर्फ़ एक प्लेटफ़ॉर्म के लिए चाहिए, या दोनों संस्करण काफ़ी अलग हैं।

क्रॉस-प्लेटफ़ॉर्म, अगर

दोनों प्लेटफ़ॉर्म पर एक जैसी सुविधाएँ हैं, और बदलाव एक साथ दिखने ज़रूरी हैं;
ऐप मुख्यतः फ़ॉर्म, सूचियों, डेटा प्रदर्शन और नोटिफ़िकेशन से बना है (ज़्यादातर व्यावसायिक ऐप ऐसे हैं);
लंबे समय तक एक टीम ऐप का रखरखाव करेगी;
कंपनी पहले से फ़्रेमवर्क की भाषा जानती है, जैसे वेब का React ज्ञान React Native की ओर, .NET पृष्ठभूमि .NET MAUI की ओर ले जाती है।

PWA या वेब ऐप, अगर

उपयोगकर्ता ऐप स्टोर में नहीं ढूँढते, बल्कि लिंक या वेबसाइट से आते हैं;
डिवाइस तक गहरी पहुँच की ज़रूरत नहीं;
ऐप को डेस्कटॉप और फ़ोन पर एक जैसा चलना है;
स्टोर समीक्षा के बिना तेज़ अपडेट प्लेटफ़ॉर्म सुविधाओं से ज़्यादा अहम हैं।

यहाँ भी सीमाएँ धुंधली हैं। जैसे Kotlin Multiplatform में व्यावसायिक तर्क साझा और UI नेटिव रह सकता है; Flutter और React Native में कोई अहम हिस्सा नेटिव कोड में भी लिखा जा सकता है। हमारी वेबसाइट का गेम वेब ऐप है: बिना इंस्टॉलेशन ब्राउज़र में, डेस्कटॉप और फ़ोन पर एक जैसा चलता है। वेब रास्ता वेबसाइट और वेब ऐप्लिकेशन विकास पृष्ठ पर है।

बैकएंड और एडमिन इंटरफ़ेस

मोबाइल ऐप शायद ही अकेला होता है। उपयोगकर्ता खाते, साझा डेटा या नोटिफ़िकेशन होते ही पीछे सर्वर चाहिए: वहीं खाते, डेटा और अनुमतियाँ रहती हैं, और वहीं से नोटिफ़िकेशन जाते हैं। पुश नोटिफ़िकेशन बैकएंड आमतौर पर अलग सेवा से भेजता है; जैसे Firebase Cloud Messaging प्लेटफ़ॉर्म-स्वतंत्र मैसेजिंग समाधान है, जिसमें विश्वसनीय सर्वर वातावरण Apple, Android और वेब ऐप को संदेश बनाकर भेजता है (Firebase: Cloud Messaging)।

एडमिन इंटरफ़ेस बैकएंड का नियंत्रण पैनल है: ब्राउज़र से सामग्री, उपयोगकर्ता और सेटिंग्स संभाली जाती हैं, ताकि रोज़ के बदलावों के लिए डेवलपर न लगे। यहीं हम कंपनी के मौजूदा सिस्टम (CRM, स्टॉक रिकॉर्ड या इनवॉइसिंग प्रोग्राम) जोड़ते हैं, ताकि ऐप बाक़ी कंपनी वाले डेटा से ही काम करे। ऐसा सिस्टम न हो, तो उसे भी कस्टम सॉफ़्टवेयर के रूप में बनाते हैं। नेटिव या क्रॉस-प्लेटफ़ॉर्म निर्णय बैकएंड को नहीं छूता: एक ही सर्वर नेटिव और Flutter ऐप, दोनों को सेवा दे सकता है।

स्टोर में प्रकाशन: अक्टूबर 2026 में किन बातों का ध्यान रखें?

स्टोर नियम अक्सर बदलते हैं, इसलिए नीचे की बातें तिथि सहित दी गई हैं (17 अक्टूबर 2026 को जाँचा गया)।

App Store (Apple)

समीक्षा दिशानिर्देश: App Store Review Guidelines पिछली बार 16 अक्टूबर 2026 को अपडेट हुए। खंड 2.1: समीक्षा को तैयार, पूरा संस्करण भेजना है; लॉगिन हो, तो डेमो अकाउंट देना है, और समीक्षा में बैकएंड चालू रहे। खंड 5.1.1: हर ऐप में गोपनीयता नीति का लिंक हो, और अकाउंट बन सके, तो उसे हटाने का विकल्प भी ऐप में हो (Apple: App Store Review Guidelines)।
गोपनीयता विवरण: App Store Connect में ऐप की डेटा प्रथाएँ बतानी होती हैं, शामिल बाहरी घटकों (जैसे एनालिटिक्स SDK) की भी; यह नए ऐप और अपडेट, दोनों के सबमिशन के लिए ज़रूरी है (Apple: App privacy details)।
डेवलपमेंट टूल की शर्त: 28 अप्रैल 2026 से App Store Connect पर अपलोड ऐप Xcode 26 या नए से, iOS 26 SDK के साथ बनने चाहिए, और 9 सितंबर 2026 से iOS और iPadOS ऐप कम से कम iOS 13 लक्षित करें (Apple: Upcoming requirements)।
कंपनी अकाउंट: संगठन के रूप में पंजीकरण के लिए कंपनी D-U-N-S नंबर वाली क़ानूनी इकाई हो, और पंजीकरण करने वाले को कंपनी की ओर से दायित्व लेने का अधिकार हो (Apple: Enrollment)।
यूरोपीय संघ में व्यापारी स्थिति: Apple पूछता है कि डेवलपर यूरोपीय संघ के क़ानून के तहत व्यापारी (trader) है या नहीं; व्यापारियों के संपर्क विवरण यूरोपीय संघ में ऐप के स्टोर पेज पर दिखते हैं (Apple: Digital Services Act trader requirements)।

Google Play

लक्षित API स्तर: 31 अगस्त 2026 से फ़ोन के नए ऐप और अपडेट को कम से कम Android 16 (API स्तर 36) लक्षित करना होता है; मौजूदा ऐप को कम से कम Android 15 (API स्तर 35), ताकि नए Android संस्करण वाले डिवाइस पर नए उपयोगकर्ताओं को भी मिलें। Play Console में माँगे गए विस्तार के साथ समय-सीमा 1 नवंबर 2026 है (Android Developers: Target API level)।
निजी अकाउंट में परीक्षण: 13 नवंबर 2023 के बाद बने निजी डेवलपर अकाउंट में प्रोडक्शन रिलीज़ से पहले कम से कम 12 परीक्षकों के साथ बंद परीक्षण चलाना होता है, जो कम से कम 14 दिन से लगातार उसमें शामिल हों (Play Console Help: testing requirements)।
संगठन अकाउंट: संगठन का डेवलपर अकाउंट D-U-N-S नंबर के बिना नहीं बन सकता (Play Console Help: creating an account)।
डेटा सुरक्षा फ़ॉर्म: Google Play पर प्रकाशित हर ऐप के लिए भरना होता है, भले ही ऐप उपयोगकर्ता डेटा न जुटाए (Play Console Help: Data safety)।
अकाउंट हटाना: ऐप में अकाउंट बन सके, तो अकाउंट और जुड़े डेटा को हटाने का अनुरोध ऐप के भीतर और एक वेब लिंक से भी संभव हो (Play Console Help: account deletion requirements)।

ये नियम तकनीक से स्वतंत्र हैं: Flutter या React Native ऐप को भी नेटिव जैसी लक्षित API और SDK शर्तें पूरी करनी हैं, इसलिए फ़्रेमवर्क अपडेट इनके साथ चलें। हमारी सलाह: डेवलपर अकाउंट ग्राहक की कंपनी का हो; तब ऐप आपकी कंपनी के नाम से दिखता है, और स्टोर लिस्टिंग कंपनी के पास रहती है।

सुलभता

दोनों प्लेटफ़ॉर्म में बिल्ट-इन स्क्रीन रीडर है (iOS पर VoiceOver, Android पर TalkBack), और ऐप को इन सहायक तकनीकों के साथ काम कराने के इंटरफ़ेस भी (React Native: Accessibility)। जैसे Flutter दस्तावेज़ीकरण सुझाता है: स्क्रीन रीडर हर नियंत्रण समझने योग्य ढंग से बताए, टेक्स्ट-पृष्ठभूमि कंट्रास्ट कम से कम 4.5:1 हो, और हर छूने योग्य तत्व कम से कम 48×48 पिक्सेल का हो (Flutter: Accessibility)। Android दस्तावेज़ीकरण ग़लतियाँ खोजने के लिए Material Design दिशानिर्देश, Accessibility Scanner टूल और स्वचालित जाँच सुझाता है (Android Developers: Accessibility)।

यह सिर्फ़ अच्छी प्रथा नहीं: निर्देश (EU) 2019/882 के अनुसार सदस्य देश 28 जून 2025 से मोबाइल ऐप वाली सेवाओं समेत उपभोक्ता ई-कॉमर्स सेवाओं पर सुलभता आवश्यकताएँ लागू करते हैं (हंगरी के नियम इसी पर आधारित हैं); सेवा देने वाले सूक्ष्म उद्यमों को छूट देनी होती है (EUR-Lex: निर्देश (EU) 2019/882)। वेबशॉप के विवरण वेबशॉप: किराए का सिस्टम या कस्टम विकास? लेख में।

कृत्रिम बुद्धिमत्ता: डिवाइस पर या क्लाउड में?

मोबाइल ऐप में AI सुविधा दो जगह चल सकती है: ख़ुद फ़ोन पर, या बैकएंड के ज़रिए क्लाउड के बड़े भाषा मॉडल में।

डिवाइस पर (Apple): Apple का Foundation Models फ़्रेमवर्क iOS 26 से Apple Intelligence के लिए बने, डिवाइस और Private Cloud Compute पर चलने वाले मॉडलों तक पहुँच देता है; यह टेक्स्ट बनाने, संरचित आउटपुट और अपने टूल बुलाने में काम आता है, पर सिर्फ़ Apple Intelligence समर्थित डिवाइस पर (Apple: Foundation Models)।
डिवाइस पर (Android): Gemini Nano, Android की AICore सिस्टम सेवा में चलता है और ML Kit GenAI इंटरफ़ेस से उपलब्ध है, जैसे सारांश, प्रूफ़रीडिंग, दोबारा लिखने और चित्र विवरण के लिए। Google के अनुसार यह नेटवर्क के बिना भी चलता है और संवेदनशील डेटा डिवाइस पर रहता है, पर मॉडल को टोकन सीमा और डिवाइस का हार्डवेयर सीमित करते हैं (Android Developers: Gemini Nano)।
क्लाउड में: OpenAI (ChatGPT), Anthropic (Claude) और Google (Gemini) के बड़े भाषा मॉडल जटिल कामों के लिए, जैसे कंपनी की अपनी सामग्री से जवाब देने वाला सहायक, दस्तावेज़ और चित्र प्रसंस्करण, सारांश। AI सेवा की एक्सेस कुंजी बैकएंड पर रहती है, फ़ोन पर नहीं: ऐप से उसे निकाला नहीं जा सकता, और उपयोग सर्वर पर नियंत्रित होता है।

डिवाइस वाला मॉडल डेटा संरक्षण और ऑफ़लाइन काम के लिए आकर्षक है, पर हर उपयोगकर्ता के डिवाइस पर उपलब्ध नहीं, इसलिए आमतौर पर इसे क्लाउड बैकअप के साथ डिज़ाइन करना उचित है। मॉडल जोड़ना AI एकीकरण पृष्ठ पर है।

रखरखाव किस पर निर्भर करता है?

हस्तांतरण के बाद भी मोबाइल ऐप पूरा नहीं होता: उसका परिवेश लगातार बदलता है। रखरखाव का काम मुख्यतः इनसे तय होता है:

ऑपरेटिंग सिस्टम और स्टोर की शर्तें: Apple अपलोड के लिए नए Xcode और SDK संस्करण माँगता है, Google Play नया लक्षित API स्तर; ऊपर की तारीख़ें दिखाती हैं कि ये नियमित रूप से बढ़ते हैं।
स्टोर दिशानिर्देशों में बदलाव: नई गोपनीयता घोषणाएँ, अकाउंट हटाने या परीक्षण के नियम।
फ़्रेमवर्क अपडेट: क्रॉस-प्लेटफ़ॉर्म ऐप में Flutter, React Native या .NET MAUI का बड़ा संस्करण बदलाव अपने कोड और प्लगइन में भी काम ला सकता है।
बाहरी घटक: भुगतान, मैप, एनालिटिक्स SDK, जिनकी अपनी अपडेट शर्तें हैं।
बैकएंड और एकीकरण: जुड़े कंपनी सिस्टमों और AI सेवाओं के इंटरफ़ेस में बदलाव।
कोडबेस की संख्या: दो नेटिव ऐप में बदलाव दो जगह करना होता है।

अक्सर होने वाली ग़लतियाँ

तकनीक टीम की आदत तय करती है, ऐप की सुविधाएँ नहीं।
सिर्फ़ स्क्रीन गिनी जाती हैं, बैकएंड और एडमिन इंटरफ़ेस नहीं।
वेबसाइट को सिर्फ़ ऐप में लपेटा जाता है, और स्टोर उसे अस्वीकार कर देता है।
डेवलपर अकाउंट विकास कंपनी के नाम पर है, और स्टोर लिस्टिंग बाद में स्थानांतरित नहीं हो सकती।
अकाउंट हटाना, गोपनीयता विवरण या डेमो अकाउंट सबमिशन के दिन जोड़े जाते हैं।
हस्तांतरण के बाद अपडेट का कोई मालिक नहीं, और नियम बदलने पर ऐप नए उपयोगकर्ताओं की नज़र से हट जाता है।

अक्सर पूछे जाने वाले प्रश्न

नेटिव या Flutter/React Native?

ऐप डिवाइस का गहराई से उपयोग करे (कैमरा, सेंसर, बैकग्राउंड प्रक्रियाएँ) या उसे ज़्यादा प्रदर्शन चाहिए, तो नेटिव विकास सुरक्षित रास्ता है। दोनों प्लेटफ़ॉर्म पर एक जैसी सुविधाएँ हों, तो Flutter या React Native से बना साझा कोडबेस वाला ऐप रखरखाव में सरल है। Kotlin Multiplatform बीच का रास्ता है: साझा व्यावसायिक तर्क, नेटिव UI। पहले परामर्श में हम ठोस सुविधाओं के आधार पर सुझाव देते हैं।

वेब ऐप (PWA) कब काफ़ी है?

जब उपयोगकर्ता लिंक या वेबसाइट से आते हैं, डिवाइस तक गहरी पहुँच नहीं चाहिए, और ऐप डेस्कटॉप और फ़ोन पर एक जैसा चलना चाहिए। यह होम स्क्रीन पर इंस्टॉल होता है और iOS पर भी पुश नोटिफ़िकेशन भेज सकता है, पर स्टोर में उपस्थिति नहीं देता, और डिवाइस सुविधाओं का दायरा ब्राउज़र पर निर्भर है।

क्या बैकएंड चाहिए?

लगभग हमेशा: ऐप में उपयोगकर्ता खाते, साझा डेटा या नोटिफ़िकेशन होते ही पीछे सर्वर चाहिए। अपवाद वह ऐप है, जो डेटा सिर्फ़ डिवाइस पर रखता है। हम बैकएंड और एडमिन इंटरफ़ेस भी बनाते हैं, और उन्हें कंपनी के मौजूदा सिस्टमों से जोड़ते हैं।

स्टोर में ऐप कौन डालता है?

प्रकाशन हम संभालते हैं: स्टोर लिस्टिंग की सामग्री और गोपनीयता घोषणाएँ तैयार करते हैं, ऐप सबमिट करते हैं, और समीक्षा तक साथ रहते हैं। हमारी सलाह: डेवलपर अकाउंट आपकी कंपनी का हो; संगठन अकाउंट के लिए दोनों स्टोर D-U-N-S नंबर माँगते हैं, इसे समय पर लें।

रखरखाव की लागत किस पर निर्भर करती है?

इस पर कि कितने कोडबेस का रखरखाव करना है, ऑपरेटिंग सिस्टम और स्टोर की शर्तें कितनी बार बदलती हैं, ऐप कितने बाहरी घटक और एकीकरण इस्तेमाल करता है, और कितना आगे का विकास अपेक्षित है। विकास की क़ीमत हम कार्यात्मक आकार से तय करते हैं; पद्धति मूल्य निर्धारण पृष्ठ पर।

हम कैसे मदद करते हैं?

हम iOS और Android ऐप विकसित करते हैं: पीछे बैकएंड और एडमिन इंटरफ़ेस बनाते हैं, AI जोड़ते हैं, और ऐप को स्टोर में प्रकाशन तक ले जाते हैं। नेटिव या क्रॉस-प्लेटफ़ॉर्म का निर्णय हम सुविधाओं के आधार पर आपके साथ लेते हैं। सेवा का विवरण मोबाइल ऐप विकास पृष्ठ पर।

हम विकास का कार्यात्मक आकार COSMIC फ़ंक्शन पॉइंट (ISO/IEC 19761) में मापते हैं, और इसी से प्रस्ताव और समय-सारिणी बनती है। पहला परामर्श निःशुल्क है, अनुरोध पर हम गोपनीयता समझौता (NDA) करते हैं, और हस्तांतरण के बाद हम संचालन और रखरखाव की ज़िम्मेदारी भी लेते हैं। सोर्स कोड और उपयोग के अधिकार अनुबंध में तय होते हैं। अपना विचार कुछ वाक्यों में लिखें और हमसे संपर्क करें।