Every product team eventually reaches the same fork in the road. Do you write separate Swift and Kotlin codebases for iO

എല്ലാ പ്രൊഡക്റ്റ് ടീമുകളും ഒടുവിൽ ഒരേ ഒരു തീരുമാനത്തിൽ എത്തും. നിങ്ങൾ iOS-നും Android-നും വേണ്ടി പ്രത്യേകമായി Swift, Kotlin കോഡ്ബേസുകൾ എഴുതണോ, അതോ React Native അല്ലെങ്കിൽ Ionic ഉപയോഗിച്ച് ഒരു സിംഗിൾ ക്രോസ്-പ്ലാറ്റ്‌ഫോം പ്രോജക്റ്റിൽ പന്തയം വെക്കണോ? രണ്ട് പ്ലാറ്റ്‌ഫോമുകൾക്കും ഒരൊറ്റ കോഡ്ബേസ് വാഗ്ദാനം ചെയ്യുന്ന ടൂളുകൾക്ക് വലിയ ആകർഷണമുണ്ട്. അവ നിങ്ങളുടെ പ്രാരംഭ സമയക്രമം കുറയ്ക്കാനും, ലോഞ്ച് ചിലവ് ലഘൂകരിക്കാനും, പ്ലാറ്റ്‌ഫോം പ്രത്യേക ഭാഷകൾ പഠിക്കാതെ തന്നെ വെബ് സാങ്കേതികവിദ്യ അറിയാവുന്ന ഒരു ടീമിന് മൊബൈൽ ആപ്പുകൾ പുറത്തിറക്കാൻ സഹായിക്കുകയും ചെയ്യും. ഈ ഗുണങ്ങൾ യഥാർത്ഥമാണ്, ചില പ്രോജക്റ്റുകളിൽ അവ നിർണ്ണായകവുമാണ്. എന്നാൽ ലോഞ്ചിന് ശേഷം യഥാർത്ഥ ഉപയോക്താക്കൾ യഥാർത്ഥ ഉപകരണങ്ങളിൽ ആപ്പ് ഉപയോഗിച്ചു തുടങ്ങുമ്പോൾ ചില പോരായ്മകൾ പ്രകടമാകും. നേറ്റീവ് ഡെവലപ്‌മെന്റിന് സമയവും വൈദഗ്ധ്യവും കൂടുതൽ ആവശ്യമാണെങ്കിലും, ക്രോസ്-പ്ലാറ്റ്‌ഫോം ഫ്രെയിംവർക്കുകൾക്ക് എത്തിപ്പിടിക്കാൻ പ്രയാസമുള്ള മേഖലകളിൽ അത് മികച്ച ഫലം നൽകുന്നു.

അബ്‌സ്‌ട്രാക്ഷൻ മൂലമുള്ള പെർഫോമൻസ് നഷ്ടം

നേറ്റീവ് ആപ്പുകൾ പ്ലാറ്റ്‌ഫോം SDK-യുമായി നേരിട്ട് ബന്ധപ്പെട്ട് പ്രവർത്തിക്കുന്നു. ഇതിലൂടെ ലഭിക്കുന്ന ബൈനറി, ഒരു ഇന്റർപ്രെറ്ററോ ഇടനിലക്കാരനോ ഇല്ലാതെ തന്നെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ഭാഷയിൽ സംസാരിക്കുന്നു. അവ വേഗത്തിൽ തുറക്കാനും, സ്ക്രോളിംഗ് സുഗമമാകാനും, കുറഞ്ഞ മെമ്മറി ഉപയോഗിക്കാനും സഹായിക്കുന്നു. RAM കുറഞ്ഞതും താപനില ഉയരാൻ സാധ്യതയുള്ളതുമായ കുറഞ്ഞ നിലവാരത്തിലുള്ള ഉപകരണങ്ങളിൽ, ഈ കാര്യക്ഷമത വളരെ പ്രധാനമാണ്. ഒരു ആപ്പ് ബാക്ക്ഗ്രൗണ്ടിൽ പ്രവർത്തിക്കണോ അതോ ഉപയോക്താവ് മറ്റൊരു ടാസ്കിലേക്ക് മാറുമ്പോൾ തന്നെ സിസ്റ്റം ആ ആപ്പിനെ നിർത്തിക്കണോ എന്നത് ഈ കാര്യക്ഷമതയെ ആശ്രയിച്ചിരിക്കും.

React Native മറ്റൊരു രീതിയാണ് സ്വീകരിക്കുന്നത്. ലോജിക് കൈകാര്യം ചെയ്യുന്നതിനായി ഇത് ഒരു JavaScript thread പ്രവർത്തിപ്പിക്കുന്നു, ഈ thread ഒരു bridge വഴി നേറ്റീവ് UI മോഡ്യൂളുകളുമായി ആശയവിനിമയം നടത്തുന്നു. ലളിതമായ സ്ക്രീനുകളിൽ ഈ താമസം ശ്രദ്ധിക്കപ്പെടില്ല. എന്നാൽ ഉയർന്ന ഫ്രീക്വൻസിയിലുള്ള അപ്‌ഡേറ്റുകൾ പ്രോസസ്സ് ചെയ്യാൻ ആവശ്യപ്പെടുമ്പോൾ, ആ bridge ഒരു തടസ്സമായി മാറുന്നു. ലൈവ് സെൻസർ ഡാറ്റ, മാപ്പ് റെൻഡറിംഗിലെ വേഗത്തിലുള്ള മാറ്റങ്ങൾ, അല്ലെങ്കിൽ സങ്കീർണ്ണമായ ലിസ്റ്റ് ആനിമേഷനുകൾ എന്നിവ JS, UI threads എന്നിവ തമ്മിലുള്ള ഏകോപനം നഷ്ടപ്പെടാൻ കാരണമാകും. ഇതിന്റെ ഫലമായി ആനിമേഷനുകൾ തടസ്സപ്പെടുകയും (dropped frames) ഉപയോഗിക്കുമ്പോൾ അസ്വാഭാവികത അനുഭവപ്പെടുകയും ചെയ്യുന്നു, ഇത് നേറ്റീവ് കോഡിൽ സംഭവിക്കില്ല.

Ionic പൂർണ്ണമായും ഒരു WebView-യ്ക്കുള്ളിലാണ് പ്രവർത്തിക്കുന്നത് എന്നതിനാൽ, ഒരു ബ്രൗസർ എഞ്ചിന്റെ ഭാരം അത് ഏറ്റെടുക്കുന്നു. കഠിനമായ കമ്പ്യൂട്ടേഷണൽ ജോലികൾ, വലിയ മെമ്മറി ഉപയോഗം, അല്ലെങ്കിൽ വലിയ അസറ്റ് പൈപ്പ്‌ലൈനുകൾ എന്നിവ ഇന്റർഫേസിനെ മന്ദഗതിയിലാക്കുന്ന garbage collection pauses ഉണ്ടാക്കിയേക്കാം. നേറ്റീവ് ടൂൾകിറ്റുകളിൽ സെക്കൻഡിൽ അറുപത് ഫ്രെയിമുകൾ വേഗതയിൽ പ്രവർത്തിക്കുന്ന ആനിമേഷനുകൾ പോലും, ഉപകരണത്തിന് കൂടുതൽ ജോലി ചെയ്യേണ്ടി വരുമ്പോൾ തടസ്സപ്പെടാം.

യൂസർ എക്സ്പീരിയൻസും പ്ലാറ്റ്‌ഫോം രീതികളും

Apple-ഉം Google-ഉം അവരുടെ ഇന്റർഫേസ് ഭാഷകൾ പരിഷ്കരിക്കാൻ വർഷങ്ങൾ ചെലവഴിച്ചിട്ടുണ്ട്. നേറ്റീവ് ഡെവലപ്‌മെന്റ് ഈ ടൂൾകിറ്റുകളിലേക്ക് നിങ്ങൾക്ക് നേരിട്ടുള്ള പ്രവേശനം നൽകുന്നു. ഫിസിക്സ് അടിസ്ഥാനമാക്കിയുള്ള സ്ക്രോളിംഗ്, ടക്റ്റൈൽ ഹാപ്റ്റിക് ഫീഡ്‌ബാക്ക്, ഉപയോക്താക്കൾ ആ പ്ലാറ്റ്‌ഫോമിൽ പ്രതീക്ഷിക്കുന്ന രീതിയിലുള്ള ജെസ്റ്റർ നാവിഗേഷൻ എന്നിവ നിങ്ങൾക്ക് ഇതിലൂടെ ലഭിക്കുന്നു.

ക്രോസ്-പ്ലാറ്റ്‌ഫോം ഫ്രെയിംവർക്കുകൾ ഈ രീതികളെ അനുകരിക്കാൻ ശ്രമിക്കുന്നുണ്ടെങ്കിലും, പലപ്പോഴും അവ പൂർണ്ണതയോടെ പ്രവർത്തിക്കാറില്ല. ഒരു React Native ആപ്പ് ശരിയാണെന്ന് തോന്നിയേക്കാം, എന്നാൽ ഒരു edge-swipe ജെസ്റ്റർ ഫ്രെയിംവർക്കിന്റെ നാവിഗേറ്ററുമായി കൂട്ടിമുട്ടുകയോ, അല്ലെങ്കിൽ കീബോർഡ് ആനിമേഷൻ സ്ക്രീനിന്റെ മറ്റ് ഭാഗങ്ങളേക്കാൾ പിന്നിലാവുകയോ ചെയ്യുമ്പോൾ പ്രശ്നങ്ങൾ പ്രകടമാകും. Ionic ആപ്പുകൾ വെബിന്റെ ഇൻപുട്ട് ഇവന്റ് മോഡൽ പിന്തുടരുന്നതിനാൽ, വേഗത്തിലുള്ള ടാപ്പുകൾ നടത്തുമ്പോൾ ഉപയോക്താവിന് ചെറിയ കാലതാമസം (latency) അനുഭവപ്പെട്ടേക്കാം.

ബാങ്കിംഗ്, ഹെൽത്ത്, അല്ലെങ്കിൽ പ്രീമിയം പ്രൊഡക്റ്റിവിറ്റി ആപ്പുകൾ എന്നിവയിൽ ഉപയോക്താക്കൾ ഉയർന്ന നിലവാരം പ്രതീക്ഷിക്കുന്നു. ഇൻസ്റ്റന്റ് ആയി തോന്നുന്ന ബയോമെട്രിക് ഫ്ലോകൾ, സ്പർശിക്കുമ്പോൾ പ്രതികരിക്കുന്ന ബട്ടണുകൾ, സ്വാഭാവികമായ ചലനങ്ങൾ (transitions) എന്നിവ അവർ ആഗ്രഹിക്കുന്നു. ഒരു സ്പ്രിംഗ് ആനിമേഷന്റെ damping ratio മുതൽ ഒരു ഹാപ്റ്റിക് പൾസിന്റെ കൃത്യമായ സമയം വരെ, ഓരോ സൂക്ഷ്മമായ ഇടപെടലിലും (micro-interaction) നിങ്ങൾക്ക് പൂർണ്ണ നിയന്ത്രണം നേറ്റീവ് കോഡ് നൽകുന്നു. ഒരു ട്രാൻസ്‌ലേഷൻ ലെയറിലൂടെ ഇത്രയും മികച്ച ഗുണനിലവാരം എത്തിക്കുക പ്രയാസകരമാണ്.

ഹാർഡ്‌വെയർ ആക്സസ്സും പ്ലഗിൻ വൈകലും

പുതിയ സെൻസറുകളോ ക്യാമറ സൗകര്യങ്ങളോ വരുമ്പോൾ, അവ ആദ്യം നേറ്റീവ് SDK-കളിലാണ് എത്തുന്നത്. LiDAR ഡെപ്ത്ത് മാപ്പിംഗ് അല്ലെങ്കിൽ അഡ്വാൻസ്ഡ് കമ്പ്യൂട്ടേഷണൽ ഫോട്ടോഗ്രാഫി പൈപ്പ്‌ലൈനുകൾ പോലുള്ള ഫീച്ചറുകൾ Swift, Kotlin ഡെവലപ്പർമാർക്ക് ആദ്യ ദിവസം തന്നെ ലഭ്യമാകും. മറ്റുള്ളവർക്ക് കമ്മ്യൂണിറ്റിയോ ഫ്രെയിംവർക്ക് വെണ്ടറോ ഒരു bridge plugin നിർമ്മിച്ചു പരീക്ഷിച്ചു തീരുന്നത് വരെ കാത്തിരിക്കേണ്ടി വരും. ഈ കാത്തിരിപ്പ് മാസങ്ങളോളം നീണ്ടുനിൽക്കാം. റിലീസ് ചെയ്തതിന് ശേഷവും, പ്ലഗിൻ പൂർണ്ണമായ API-യുടെ ഒരു ഭാഗം മാത്രമേ നൽകുന്നുള്ളൂ എങ്കിൽ, ഹാർഡ്‌വെയർ നൽകുന്ന കൃത്യമായ നിയന്ത്രണം നിങ്ങൾക്ക് ലഭിക്കില്ല.

നേറ്റീവ് കോഡിലൂടെ ഈ ഫീച്ചറുകൾ ഉപയോഗിക്കുന്നത് കൂടുതൽ ലളിതവും വിശ്വസനീയവുമാണ്, കാരണം നിങ്ങൾ നേരിട്ട് നിർമ്മാതാവിന്റെ ഫ്രെയിംവർക്കുകളെയാണ് വിളിക്കുന്നത്. ഒരു ഇടനിലക്കാരൻ (intermediate wrapper) ഹെഡറുകൾ ശരിയായി വായിച്ചോ എന്ന് ആശങ്കപ്പെടാതെ, ഡോക്യുമെന്റേഷനിൽ പറഞ്ഞിരിക്കുന്നതുപോലെ തന്നെ നിങ്ങൾക്ക് എക്സ്പോഷർ മാട്രിക്സുകൾ, ഡെപ്ത്ത് ബഫറുകൾ അല്ലെങ്കിൽ സ്പേഷ്യൽ ഡാറ്റ എന്നിവ കോൺഫിഗർ ചെയ്യാം.

പ്ലഗിനുകൾ ഒരു പരിപാലന ബാധ്യതയും (maintenance liability) ഉണ്ടാക്കുന്നു. ഓരോ പ്രധാനപ്പെട്ട OS അപ്‌ഡേറ്റും ഒരു ക്രോസ്-പ്ലാറ്റ്‌ഫോം ഡിപെൻഡൻസിയെ (cross-platform dependency) തകരാറിലാക്കാൻ സാധ്യതയുണ്ട്. അത് പാച്ച് ചെയ്യാനും (patch), പരിശോധിക്കാനും (validate), പുതിയ പതിപ്പ് പുറത്തിറക്കാനും (ship) ആരെങ്കിലും ഉണ്ടാവണം. അതിന്റെ യഥാർത്ഥ നിർമ്മാതാവ് മാറിപ്പോയിട്ടുണ്ടെങ്കിൽ, നിങ്ങളുടെ ടീമിന് ആ ജോലി ഏറ്റെടുക്കേണ്ടി വരും അല്ലെങ്കിൽ പകരം മറ്റൊരാളെ കണ്ടെത്തേണ്ടി വരും. നേറ്റീവ് ഡെവലപ്‌മെന്റ് (Native development) കംപാറ്റിബിലിറ്റി ജോലികൾ ഇല്ലാതാക്കുന്നില്ല, എന്നാൽ മറ്റൊരാളുടെ ഷെഡ്യൂളിനെ ആശ്രയിക്കേണ്ടി വരുന്ന അധിക ഇൻഡയറക്ഷൻ ലെയറുകളെ (indirection layer) അത് ഒഴിവാക്കുന്നു.

സുരക്ഷയും ഡിപെൻഡൻസി സർഫേസും (Security and the Dependency Surface)

നേറ്റീവ് ആപ്ലിക്കേഷനുകൾ പ്ലാറ്റ്‌ഫോമിന്റെ സുരക്ഷാ മാതൃകയുമായി (security model) നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നു. iOS-ൽ, നിങ്ങൾ ഓതന്റിക്കേഷൻ ടോക്കണുകളോ (authentication tokens) ക്രിപ്റ്റോഗ്രാഫിക് മെറ്റീരിയലുകളോ Keychain-ൽ സൂക്ഷിക്കുന്നു. Android-ൽ, നിങ്ങൾ Keystore സിസ്റ്റവുമായി സംയോജിപ്പിക്കുകയും ഉപകരണം പിന്തുണയ്ക്കുന്നിടത്ത് ഹാർഡ്‌വെയർ അധിഷ്ഠിത എൻക്രിപ്ഷൻ (hardware-backed encryption) ആവശ്യപ്പെടുകയും ചെയ്യുന്നു. ഇവ പ്ലാറ്റ്‌ഫോം വെണ്ടർ പരിശോധിച്ച് ഉറപ്പുവരുത്തിയതും ഡെഡിക്കേറ്റഡ് സിലിക്കൺ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതുമായ ഫസ്റ്റ് ക്ലാസ് APIs ആണ്.

ക്രോസ്-പ്ലാറ്റ്‌ഫോം സൊല്യൂഷനുകൾ നിങ്ങളുടെ ലോജിക്കും OS സുരക്ഷാ പ്രിമിറ്റീവ്സും (security primitives) ഇടയിൽ അധിക ലെയറുകൾ ചേർക്കുന്നു. ഒരു React Native ആപ്പ് സെൻസിറ്റീവ് ഡാറ്റ ഒരു അബ്സ്ട്രാക്ഷൻ മോഡ്യൂൾ (abstraction module) വഴി ലോക്കൽ സ്റ്റോറേജിൽ സൂക്ഷിച്ചേക്കാം. പെർമിഷനുകൾ ശരിയാണെന്നും, ക്ലൗഡ് സ്റ്റോറേജിലേക്കുള്ള അവിചാരിതമായ ബാക്കപ്പുകൾ ഒഴിവാക്കിയിട്ടുണ്ടെന്നും, ലോഗിംഗിലൂടെ ഡാറ്റ ചോരുന്നില്ലെന്നും നിങ്ങൾ പരിശോധിക്കേണ്ടതുണ്ട്. ഇൻപുട്ട് സാനിറ്റൈസേഷൻ (input sanitization) പരാജയപ്പെട്ടാൽ ഇൻജക്ഷൻ സാധ്യതകൾ വർദ്ധിപ്പിക്കുന്ന ഒരു JavaScript കോൺടെക്സ്റ്റുള്ള WebView-യ്ക്കുള്ളിലാണ് Ionic ആപ്പുകൾ പ്രവർത്തിക്കുന്നത്.

ഓരോ പ്ലഗിനും തേർഡ് പാർട്ടി ഡിപെൻഡൻസിയും നിങ്ങളുടെ അറ്റാക്ക് സർഫേസ് (attack surface) വർദ്ധിപ്പിക്കുന്നു. നിങ്ങൾ പേയ്‌മെന്റുകൾ, HIPAA പ്രകാരമുള്ള രോഗികളുടെ റെക്കോർഡുകൾ, അല്ലെങ്കിൽ PCI-DSS നിബന്ധനകൾക്ക് വിധേയമായ ഏതെങ്കിലും ഡാറ്റ എന്നിവ കൈകാര്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ ഡിപെൻഡൻസി ട്രീയെ (dependency tree) ഒരു ബ്ലാക്ക് ബോക്സ് ആയി കാണാൻ കഴിയില്ല. നിങ്ങൾ പതിപ്പുകൾ ഓഡിറ്റ് ചെയ്യുകയും, വിവരങ്ങൾ നിരീക്ഷിക്കുകയും, ചിലപ്പോൾ കോഡ് സ്വയം പാച്ച് ചെയ്യുകയും ചെയ്യേണ്ടതുണ്ട്. നേറ്റീവ് ഡെവലപ്‌മെന്റ് സുരക്ഷാ ജോലികൾ ഇല്ലാതാക്കുന്നില്ല, എന്നാൽ നിങ്ങൾ വിശ്വസിക്കേണ്ടി വരുന്ന ഘടകങ്ങളുടെ എണ്ണം അത് കുറയ്ക്കുന്നു.

ഏത് പാത തിരഞ്ഞെടുക്കണം എന്ന് തീരുമാനിക്കുമ്പോൾ

നേറ്റീവ് ഡെവലപ്‌മെന്റിന്റെ കരുത്തുണ്ടെങ്കിലും, ചില സാധാരണ സാഹചര്യങ്ങളിൽ ക്രോസ്-പ്ലാറ്റ്‌ഫോം തിരഞ്ഞെടുക്കുന്നതാണ് ബുദ്ധിപരമായ നീക്കം.

താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ നേറ്റീവ് ഡെവലപ്‌മെന്റ് തിരഞ്ഞെടുക്കുക:

• പെർഫോമൻസ് വളരെ പ്രധാനപ്പെട്ടതാണെങ്കിൽ. Augmented reality, റിയൽ-ടൈം മെഷീൻ ലേണിംഗ്, അല്ലെങ്കിൽ മൊബൈൽ ഗെയിമുകൾ എന്നിവയ്ക്ക് ഫ്രെയിം ഡ്രോപ്പുകളോ (frame drops) ബ്രിഡ്ജ് ലേറ്റൻസിയോ (bridge latency) സഹിക്കാനാവില്ല.
• ആഴത്തിലുള്ള ഹാർഡ്‌വെയർ ഇന്റഗ്രേഷൻ ആവശ്യമാണെങ്കിൽ. നിങ്ങളുടെ പ്രധാന ഫീച്ചർ കൃത്യമായ ക്യാമറ കൺട്രോൾ, കസ്റ്റം സെൻസറുകൾ, അല്ലെങ്കിൽ ലോ-ലേറ്റൻസി ഓഡിയോ എന്നിവയെ ആശ്രയിച്ചാണെങ്കിൽ, നേറ്റീവ് APIs ആണ് സുരക്ഷിതമായ അടിത്തറ.
• ഉയർന്ന നിലവാരമുള്ള UX-ഉം ആക്സസിബിലിറ്റിയും (accessibility) ഒഴിച്ചുകൂടാനാവാത്തതാണെങ്കിൽ. ഫിനാൻഷ്യൽ, മെഡിക്കൽ, പ്രീമിയം കൺസ്യൂമർ ആപ്പുകൾ മികച്ച ടാക്റ്റൈൽ ഫീലിനും (tactile feel) പ്ലാറ്റ്‌ഫോം രീതികളോടുള്ള കർശനമായ അനുസരണത്തിനും മത്സരിക്കുന്നു.
• സുരക്ഷാ നിയന്ത്രണങ്ങൾ കർശനമാണെങ്കിൽ. Fintech, ഹെൽത്ത് കെയർ ഉൽപ്പന്നങ്ങൾ കുറഞ്ഞ അറ്റാക്ക് സർഫേസും പ്ലാറ്റ്‌ഫോം കീ മാനേജ്‌മെന്റിലേക്കുള്ള നേരിട്ടുള്ള പ്രവേശനവും വഴി പ്രയോജനം ലഭിക്കുന്നു.

താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ ഒരു ക്രോസ്-പ്ലാറ്റ്‌ഫോം ഫ്രെയിംവർക്ക് തിരഞ്ഞെടുക്കുക:

• പ്ലാറ്റ്‌ഫോം പ്രത്യേക ടീമുകളിൽ നിക്ഷേപിക്കുന്നതിന് മുമ്പ് ഒരു ആശയം പരിശോധിക്കാൻ വേഗത്തിൽ ഒരു MVP ആവശ്യമുണ്ടെങ്കിൽ.
• ആപ്പ് കൂടുതൽ ഉള്ളടക്കം (content) അടിസ്ഥാനമാക്കിയുള്ളതാണെങ്കിൽ. ന്യൂസ് റീഡറുകൾ, ബ്ലോഗുകൾ, കാറ്റലോഗ് ആപ്പുകൾ എന്നിവ മിക്കവാറും സ്ക്രോളിംഗ് ടെക്സ്റ്റും ചിത്രങ്ങളും മാത്രമാണ്, ഇത് വെബ് ടെക്നോളജി ഉപയോഗിച്ച് എളുപ്പത്തിൽ കൈകാര്യം ചെയ്യാം.
• നിങ്ങളുടെ ടീമിന് മൊബൈൽ സിസ്റ്റംസ് പ്രോഗ്രാമിംഗിനേക്കാൾ വെബ് ഡെവലപ്‌മെന്റിലാണ് പ്രാവീണ്യമെങ്കിൽ.
• ബജറ്റും വിപണിയിലെത്തിയേക്കാവുന്ന സമയവും (time-to-market) പ്രധാനപ്പെട്ട ഘടകങ്ങളാണെങ്കിൽ, കൂടാതെ ആപ്പിന്റെ ഫീച്ചറുകൾ ഫ്രെയിംവർക്കിന്റെ കരുത്തിന് ഉള്ളിലാണെങ്കിൽ.

യഥാർത്ഥ പാഠം

നേറ്റീവ് വേണോ ക്രോസ്-പ്ലാറ്റ്‌ഫോം വേണോ എന്ന തീരുമാനം ഒരിക്കലും ഒരു ഫാഷൻ തീരുമാനമാകരുത്. അത് നിങ്ങളുടെ ഉപയോക്താക്കൾ ആ ആപ്പ് ഉപയോഗിക്കുന്ന രീതിയുമായി ബന്ധപ്പെട്ട ഒരു എഞ്ചിനീയറിംഗ് ട്രേഡ്-ഓഫ് (engineering trade-off) ആണ്. നിങ്ങൾ ഉള്ളടക്കം മാത്രം നൽകുന്നതോ, ഒരു മാർക്കറ്റ് പരിശോധിക്കുന്നതോ, അല്ലെങ്കിൽ ഒരു ഇന്റേണൽ ഡാഷ്‌ബോർഡ് നിർമ്മിക്കുന്നതോ ആണെങ്കിൽ, React Native അല്ലെങ്കിൽ Ionic ഉപയോഗിക്കുന്നത് പണം ലാഭിക്കാനും ആഴ്ചകളുടെ ജോലി കുറയ്ക്കാനും സഹായിക്കും. എന്നാൽ നിങ്ങളുടെ ഉൽപ്പന്നം വേഗതയിൽ മത്സരിക്കുന്നതോ, സെൻസിറ്റീവ് ഡാറ്റ കൈകാര്യം ചെയ്യുന്നതോ, അല്ലെങ്കിൽ ഹാർഡ്‌വെയറുമായി ചേർന്ന് പ്രവർത്തിക്കേണ്ടതോ ആണെങ്കിൽ, അബ്സ്ട്രാക്ഷൻ ലെയറുകൾ വരുത്തിവെക്കുന്ന വിട്ടുവീഴ്ചകൾക്കെതിരെയുള്ള ഇൻഷുറൻസ് ആണ് നേറ്റീവ് ഡെവലപ്‌മെന്റിന്റെ അധിക ചിലവ്. നിങ്ങളുടെ പ്രശ്നത്തിന്റെ പരിമിതികൾക്ക് അനുസൃതമായി നിങ്ങളുടെ സ്റ്റാക്ക് (stack) തിരഞ്ഞെടുക്കുക, അല്ലാതെ നിലവിലുള്ള ട്രെൻഡുകൾ നോക്കിയല്ല.