Натыўнае або гібрыднае мабільнае прыкладанне па замове

У чым розніца паміж натыўным і гібрыдным прыкладаннем?

Пры натыўнай распрацоўцы прыкладанне ствараецца спецыяльна для пэўнай аперацыйнай сістэмы. Для iOS звычайна выкарыстоўваюцца Swift і інструменты Apple, а для Android — Kotlin і інструменты Google. Так каманда працуе непасрэдна з магчымасцямі адпаведнай платформы.

Пры гібрыднай распрацоўцы выкарыстоўваецца агульная кодавая база для iOS і Android. На практыцы бізнес часта называе гэты падыход «гібрыдным», хоць існуе розніца паміж класічным прыкладаннем з вэб-прадстаўленнем і сучаснай кросплатформеннай распрацоўкай на Flutter або React Native. Для заказчыка важна, якая частка кода выкарыстоўваецца агульна і дзе патрэбныя асобныя рашэнні для кожнай платформы.

Калі натыўная распрацоўка з'яўляецца лепшым выбарам?

Выбірайце натыўны падыход, калі прыкладанне павінна інтэнсіўна выкарыстоўваць тэлефон. Гэта можа ўключаць складаную GPS-логіку, працу з Bluetooth-прыладамі, камеру ў рэальным часе, графічна насычаныя экраны, аўтаномны рэжым з вялікай колькасцю лакальных даных або спецыялізаваныя функцыі бяспекі.

Натыўнае прыкладанне мае сэнс і тады, калі мабільны досвед з'яўляецца асноўным прадуктам. У гульні, фінансавым прыкладанні, медыцынскай прыладзе або прыкладанні для выязных каманд невялікія адрозненні ў хуткасці і паводзінах могуць непасрэдна ўплываць на давер і працу.

Аднак гэты выбар не азначае аўтаматычна «лепшае». Калі прыкладанне паказвае каталог, прымае заказы, адпраўляе апавяшчэнні і падключаецца да CRM або ERP, натыўная распрацоўка можа дадаць працы без рэальнай карысці для бізнесу. У такім выпадку вы плаціце за дзве рэалізацыі логікі, якая можа быць аднолькавай.

Калі гібрыднага мабільнага прыкладання дастаткова?

Гібрыдны падыход падыходзіць для прыкладанняў з рэгістрацыяй, профілямі, спісамі, формамі, браняваннямі, плацяжамі, апавяшчэннямі, чатам, каталогам і падключэннем да сервера. Гэта тыповыя функцыі для гандлёвых кампаній, сэрвісных кампаній, падпісных сэрвісаў і ўнутраных прыкладанняў для супрацоўнікаў.

Гэта практычны варыянт і тады, калі вы хочаце праверыць ідэю на першай версіі, перш чым інвеставаць у асобныя прыкладанні. Можна пачаць з асноўнага сцэнарыя — рэгістрацыі, заяўкі, аплаты або задачы — а больш спецыфічныя функцыі дадаць пасля атрымання рэальнай зваротнай сувязі ад карыстальнікаў.

Пры выбары не глядзіце толькі на тое, ці будзе прыкладанне «гібрыдным». Папрасіце ўдакладніць, якія часткі будуць агульнымі, якія напішуць натыўна і як будуць абнаўляцца бібліятэкі, што выкарыстоўваюцца. Няправільна падабраныя модулі могуць стварыць праблемы пры выхадзе новай версіі iOS або Android, незалежна ад назвы тэхналогіі.

Як выбар уплывае на кошт?

Арыенцір кошту распрацоўкі мабільнага прыкладання — 200–15 000 €. Ніжняя мяжа магчымая пры абмежаваным аб’ёме і гатовых інтэграцыях. Верхняя мяжа дасягаецца пры наяўнасці ўласнага сервера, адмін-панэлі, плацяжоў, роляў, складаных працэсаў, працы без інтэрнэту, спецыфічнага абсталявання і асобных патрабаванняў для iOS і Android.

Натыўны варыянт звычайна каштуе даражэй, калі трэба распрацаваць два паўнавартасныя прыкладанні. Прычына не толькі ў мове праграмавання. Экраны, навігацыю, тэсты, апавяшчэнні, плацяжы і выпраўленні трэба праверыць у абедзвюх асяроддзях.

Гібрыдны варыянт можа скараціць дубляванне працы, але не робіць усе выдаткі агульнымі. Сервер, база даных, API-інтэграцыі, адмін-панэль, дызайн, тэсты і публікацыя застаюцца часткамі праекта. Калі патрэбен натыўны модуль для Bluetooth, GPS або бяспечнага захоўвання даных, ён таксама ўваходзіць у аб’ём работ.

Больш за ўсё на прапанову ўплывае не колькасць экранаў, а бізнес-правілы за імі. Прыкладанне для адпраўкі заяўкі ў адзін API адрозніваецца ад прыкладання з рознымі ролямі, узгадненнямі, складскімі рэшткамі, дакументамі, сінхранізацыяй і працай без інтэрнэту.

Як выбар уплывае на прадукцыйнасць і карыстальніцкі досвед?

Натыўнае прыкладанне дае найбольш непасрэдны кантроль над анімацыямі, памяццю, фонавымі працэсамі і рэакцыяй падчас цяжкіх аперацый. Гэта важна, калі карыстальнік доўга працуе ў прыкладанні або любая затрымка перашкаджае працэсу.

Для звычайнага бізнес-прыкладання гібрыдны падыход часта цалкам дастатковы. Экран з кліентамі, задачамі, фотаздымкамі, заяўкамі, статусамі і апавяшчэннямі не патрабуе такой жа аптымізацыі, як гульня або прыкладанне, якое апрацоўвае відэа ў рэальным часе.

Прадукцыйнасць залежыць і ад архітэктуры. Павольны API, няправільная загрузка выяў, адсутнасць кэшавання або дрэнна спраектаваная база даных запаволяць і натыўнае, і гібрыднае прыкладанне. Таму ў тэхнічным заданні павінны быць вымяральныя сцэнарыі: колькі даных загружаецца, што адбываецца пры слабым інтэрнэце і якія дзеянні павінны працаваць без падключэння.

Як змяняюцца падтрымка і будучыя дапрацоўкі?

Пры натыўнай распрацоўцы змяненне трэба праверыць у двух тэхналагічных асяроддзях. Гэта можа быць апраўдана, калі дзве версіі маюць розны дызайн або розныя функцыі. Аднак гэта патрабуе больш строгага кантролю версій і большага аб’ёму тэставання.

У гібрыдным прыкладанні адно змяненне агульнай логікі можа адначасова дайсці і да iOS, і да Android. Гэта спрашчае выпраўленні, але стварае іншы рызыкавы фактар: змяненне агульнага кода можа адначасова закрануць абедзве платформы. Таму важныя аўтаматызаваныя тэсты, тэставыя прылады і выразны працэс публікацыі.

У прапанове павінна быць выразна пазначана, хто падтрымлівае залежнасці, хто сочыць за новымі версіямі аперацыйных сістэм і як дзейнічаць, калі прыкладанне адхіляе крама. Таксама спытайце, ці атрымаеце вы доступ да кода, сховішчаў, сертыфікатаў і профіляў кампаніі ў App Store і Google Play.

Ці аднолькава публікуюцца прыкладанні для iOS і Android?

Пры абодвух падыходах асобныя версіі публікуюцца ў App Store і Google Play. Агульны код не адмяняе патрабаванняў крам. Патрэбны профілі распрацоўшчыка, іконкі, апісанні, здымкі экрана, дэкларацыі прыватнасці, тэставая версія і карэктнае кіраванне дазволамі.

Пры праверцы iOS асаблівая ўвага можа надавацца плацяжам, збору персанальных даных, уваходу праз знешнія профілі і выкарыстанню адчувальных функцый. Для Android дзейнічае ўласны набор патрабаванняў да дазволаў, мэтавай версіі і паводзін прыкладання.

Загадзя ўдакладніце, каму належаць профілі ў крамах. Яны павінны быць зарэгістраваныя на кампанію, а не толькі на выканаўцу. Так вы захаваеце кантроль над публікацыямі, ацэнкамі, статыстыкай і будучай заменай каманды.

Як выбраць падыход для свайго бізнесу?

1. 01
   Апішыце асноўны карыстальніцкі сцэнарый

   Запішыце, што павінен зрабіць карыстальнік ад адкрыцця прыкладання да завершанай заяўкі, аплаты, браніравання або задачы. Аддзяліце абавязковыя функцыі ад ідэй на пазнейшы этап.

2. 02
   Адзначце залежнасці ад тэлефона

   Укажыце, ці патрэбныя GPS, камера, Bluetooth, NFC, біяметрыя, праца без падключэння, фонавае адсочванне або спецыфічныя апавяшчэнні. Менавіта гэтыя патрабаванні часцей за ўсё схіляюць выбар на карысць натыўнага кода.

3. 03
   Праверце сервер і інтэграцыі

   Удакладніце, адкуль паступаюць даныя і з чым павінна інтэгравацца прыкладанне: CRM, ERP, інтэрнэт-крама, плацежная сістэма, кур’ерская служба, тэлефанія або знешні API. Мабільны інтэрфейс — толькі адна частка сістэмы.

4. 04
   Папрасіце супастаўныя прапановы

   Няхай у кожнай прапанове будуць пазначаныя платформы, код, адмін-панэль, API, тэсты, публікацыя, гарантыйныя выпраўленні і падтрымка. Інакш вы параўноўваеце розны аб’ём работ, а не розныя тэхналогіі.

5. 05
   Заплануйце першую працоўную версію

   Пачніце з працэсу, які стварае найбольшую каштоўнасць. Сачыце за рэальным выкарыстаннем і дадавайце складаныя функцыі толькі тады, калі ёсць даказаная патрэба ў іх.

Як гэта выглядае ў рэальным праекце?

FIX — дадатак для хатніх паслуг — прыклад прадукту, у якім мабільны дадатак з'яўляецца часткай большай платформы з вэб-парталам, пошукам і сувяззю паміж кліентамі і спецыялістамі. У такім рашэнні выбар не зводзіцца да экранаў у тэлефоне. Трэба спланаваць профілі, заяўкі, статусы, апавяшчэнні, серверную логіку і адміністраванне.

Менавіта таму на першай сустрэчы трэба высветліць увесь працэс, а не толькі тое, ці будзе дадатак для iOS, Android або абедзвюх платформаў. Калі мабільны прадукт звязаны з унутранай сістэмай, правільны API і выразна вызначаныя ролі часта важнейшыя за сам выбар паміж двума падыходамі.

Што павінна ўваходзіць у заданне на мабільны дадатак?

Апішыце тыпы карыстальнікаў, экраны, дзеянні, ролі і даныя, якія захоўваюцца. Дадайце патрабаванні да ўваходу, скідання пароля, апавяшчэнняў, плацяжоў, фатаграфій, дакументаў, аўтаномнага рэжыму і доступу да функцый тэлефона.

Укажыце таксама, як вы будзеце вымяраць поспех першай версіі. Гэта можа быць завершанае браніраванне, адпраўленая заяўка, падпісаны дакумент або задача, выкананая супрацоўнікам на аб'екце. Так каманда зможа прапанаваць тэхналогію ў адпаведнасці з працэсам, а не папулярнасцю пэўнага інструмента.

Калі дадатак будзе абменьвацца данымі з наяўным праграмным забеспячэннем, праверце, ці ёсць у яго API і якія ў яго абмежаванні. Калі стабільнага API няма, можа спатрэбіцца дадатковая распрацоўка, якая паўплывае на тэрміны і аб'ём работ мацней, чым выбар паміж натыўнай і гібрыднай рэалізацыяй.