S-ar părea că avem o dezvoltare multiplatformă, ceea ce face posibilă crearea de aplicații universale pentru diferite platforme. Am scris aplicația mai repede, am lansat-o imediat peste tot - profit! Și nu este nevoie de dezvoltare nativă. Sau mai este nevoie? Despre nuanțele ambelor abordări de dezvoltare aplicații mobile am întrebat experții noștri.

„Dezvoltator mobil” este un concept larg. Un dezvoltator care implementează părți ale unui sistem de operare mobil este, de asemenea, un dezvoltator mobil. Și dacă scopul este să deveniți un astfel de dezvoltator, atunci trebuie să începeți prin a studia C++, sistemul de operare mobil și hardware-ul dispozitivelor mobile.

Dacă vă referiți la un dezvoltator care implementează aplicații mobile personalizate, atunci trebuie să începeți cu dezvoltarea nativă.

De ce este așa? Dezvoltarea nativă vă permite să studiați mai bine și mai profund capacitățile sistemelor de operare specifice (și aplicațiilor pentru acestea) și hardware-ului mobil.

Din punctul de vedere al utilizatorului, dezvoltarea nativă câștigă cu siguranță. Aplicațiile native funcționează mai rapid, interfața lor este mai receptivă și mai familiară pentru utilizatorii unui anumit sistem de operare mobil, folosesc mai bine capacitățile hardware ale dispozitivului, funcționează mai bine offline și au mai puține erori.

Ideea originală a dezvoltării pe mai multe platforme este reducerea costurilor cu forța de muncă pentru dezvoltatori. Poate fi exprimat pe scurt după cum urmează: „Făcut o dată, funcționează la orice”. Ideea este bună și corectă (din punctul de vedere al dezvoltatorului), dar există probleme de calitate. Orice versatilitate vine în mod inerent cu un compromis, iar domeniul dezvoltării mobile nu face excepție.

Atunci când alege tipul de dezvoltare pentru o anumită sarcină, dezvoltatorul trebuie să evalueze cât de acceptabil este acest compromis. Există o serie de sarcini în care utilizarea dezvoltării multiplatformă va fi destul de justificată, de exemplu, în proiecte de testare, versiuni mobile de site-uri web, jocuri care utilizează cadre precum Unity 3D.

În același timp, pentru proiectele care rezolvă problemele de afaceri mobile (cu o încărcare mare, necesitatea suportării modului offline, care vizează dezvoltarea pe termen lung), dezvoltarea nativă pare să fie singura optimă (și pentru unele sarcini, singura posibilă). ) opțiunea.

În același timp, principalele dezavantaje ale dezvoltării native sunt timpul de dezvoltare (este nevoie de mai mult) și nevoia de resurse diverse (dezvoltatori în diferite limbaje de programare native). Există modalități de a atenua aceste deficiențe - de exemplu, folosiți pentru dezvoltare un fel de platformă de aplicații mobile (clasa MEAP), care vă permite să creați aplicații native.

Promovați retrogradarea

, Director pentru Dezvoltare Tehnologică al companiei IT „ID – Tehnologii de Management”

Orice bibliotecă sau cadru multiplatformă se bazează pe aceleași mecanisme native pe care dezvoltarea nativă este direct implementată. Doar că, în cazul soluțiilor cross-platform, procesele de lucru sunt construite în așa fel încât să „netezeze colțurile” în ceea ce privește aducerea interfeței soluției finale la un anumit numitor comun.

De regulă, universalismul nu este întotdeauna răspunsul la sarcina de a crea o soluție mobilă funcțională: dezvoltatorul lucrează mai bine cu cât înțelege mai bine mecanismele diferitelor procese din interior, așa cum se spune, „sub capotă”.

De asemenea, un model complet funcțional ar fi stăpânirea simultană a elementelor de bază ale celor două abordări nu este nimic imposibil într-o astfel de sarcină de învățare la etapa inițială; De exemplu, un astfel de scenariu se poate dovedi a fi destul de fezabil și promițător: începeți să lucrați într-o paradigmă multiplatformă și, în același timp, independent sau cu ajutorul colegilor, studiați ce capacități native există pentru dezvoltarea soluțiilor actuale și cum pot fi aplicate în practică.

În acest caz, este mai ușor să obțineți o înțelegere cuprinzătoare a modului în care funcționează în principiu procesul de dezvoltare mobilă, care se numește end-to-end. Acest lucru este util și pentru că orice platformă, chiar și cea mai avansată, universală rămâne în urmă față de cea nativă în ceea ce privește capacitățile sale: producătorii de hardware și sisteme de operare mobile lucrează adesea împreună și cresc constant capacitățile soluțiilor finale - capabilitățile platformelor de dezvoltare mobile, în special cross. -soluții de platformă, inevitabil rămân în urmă.

Pe piață apar în mod constant produse noi în segmentul dispozitivelor mobile, unele dintre ele fiind semnificativ înaintea timpului lor - luați Samsung și dezvoltarea sa a unui dispozitiv cu ecran îndoit: este evident că, datorită unui front-end radical diferit , platformele de dezvoltare existente nu sunt pregătite pentru astfel de lucruri.

Aici este utilă cunoașterea profundă a platformelor native: doar un dezvoltator cu cunoștințe profunde și sistemice despre dezvoltarea mobilă, adică platformele native, poate compensa decalajul natural din spatele hardware-ului și al sistemului de operare. Doar un astfel de specialist va putea crește funcționalitatea soluției sale pentru cele mai recente dispozitive mobile bazate pe platformele de dezvoltare nu în totalitate avansate disponibile în prezent.

Dezvoltarea multiplatformă este excelentă pentru prototipare, testarea rapidă a ideilor etc. De îndată ce este vorba de crearea unor produse cu adevărat fundamentale, dezvoltatorul ajunge inevitabil la nevoia de a studia profund elementele de bază ale procesului, adică dezvoltarea nativă.

Promovați retrogradarea

, Decan al Facultății de Dezvoltare iOS GeekUniversity, portal educațional GeekBrains

Răspuns scurt: dacă nu aveți experiență de programare, atunci, desigur, trebuie să alegeți dezvoltarea nativă. Dezvoltarea multiplatformă este bună pentru specialiștii care trec de la domenii conexe la dezvoltarea mobilă. De exemplu, dacă lucrați ca dezvoltator frontend, cu un bun cunoștințe de JavaScript Cu ajutorul cadrului React Native (creat pe baza cadrului React), puteți încerca rapid și fără durere să stăpâniți dezvoltarea mobilă. În mod similar, va fi mai ușor pentru un dezvoltator .NET să stăpânească cadrul Xamarin.

Dezvoltarea multiplatformă este, de asemenea, benefică pentru client - este mai ușor să găsești o echipă de dezvoltatori care, după un model comun, va dezvolta o aplicație pentru două platforme deodată.

Avantajele sunt evidente, dar care sunt dezavantajele dezvoltării multi-platformă?! Se crede că, cu cât funcționalitatea într-o aplicație mobilă este mai complexă și mai subtilă, cu atât este mai dificilă, dacă nu imposibilă, să o implementezi folosind instrumente multiplatformă - acest lucru depășește adesea toate avantajele instrumentelor universale. Din experiența mea, există mai multe companii mari care, odată cu creșterea aplicației lor, au fost forțate să renunțe la cross-platform în favoarea dezvoltării native. Astfel, pentru proiecte mici și eventual sarcini de liber profesionist este suficient solutii generale, iar pentru proiectele mari sunt mai potrivite cele native.

Cererea pentru ambele zone este destul de mare, dar pentru dezvoltarea nativă este ceva mai mare: la cerere pentru Swift pe hh.ru în Rusia - 369 de posturi vacante, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. Dar fiți siguri , un bun specialist în Nu va mai rămâne loc de muncă în niciun sector.

Promovați retrogradarea

Pentru început, este important să rețineți că orice aplicație mobilă constă din mai multe straturi:

• UI este ceea ce vede utilizatorul;
• logica de afaceri este pentru care este scrisă aplicația;
• alte componente ale platformei - lucrul cu rețeaua, bazele de date și alte componente ale sistemului care sunt utilizate de logica de afaceri.

În funcție de aplicația specifică, dimensiunea componentelor de pe aceste straturi poate varia foarte mult. De exemplu, o aplicație pentru citirea știrilor pe un site web va fi foarte diferită de un client VPN.

Dezvoltarea în sine poate fi împărțită în trei tipuri: nativ, complet multiplatform și hibrid.

Dezvoltare nativă

În dezvoltarea nativă, toate cele trei straturi sunt scrise folosind același set de instrumente. Prin urmare, ele pot interacționa între ele fără nicio complexitate suplimentară.

Avantajele dezvoltării native:

Dezvoltare hibridă

Acest tip de dezvoltare combină ambele abordări anterioare. Stratul logic de afaceri este construit ca o componentă „portabilă”, iar integrarea UI și platforma sunt create folosind instrumente standard. Există mai multe limbaje pentru scrierea logicii generale: C/C++ (soluție matură și puternică), KotlinNative (foarte activ dezvoltat) și JavaScript (cel mai puțin comun).

Avantaje:

• componentele cele mai potrivite pentru aceasta rămân native;
• logica generală se creează o dată.

Defecte:

• dacă o componentă comună va fi creată de o echipă mobilă, atunci este necesar să obțineți expertiză într-o altă limbă;
• există o suprasarcină pentru integrarea componentelor cross-platform.

Cu ce ​​tip de dezvoltare este cel mai bine să începem?

Pentru a răspunde la această întrebare, trebuie să înțelegeți ce fel de proiecte doriți să creați. Proiectele mici pot fi pur cross-platform și acest lucru va fi complet justificat. Aici te-aș sfătui să arunci o privire mai atentă la Flutter.

Dar astăzi aș începe cu dezvoltarea nativă. În primul rând, majoritatea proiectelor de astăzi sunt create nativ. Aceasta înseamnă că veți avea mai multe oportunități de a schimba proiecte/companii. În al doilea rând, în timp se va putea trece la dezvoltarea hibridă multiplatformă. Acest lucru vă va permite să creșteți în chestiuni tehnice.

Promovați retrogradarea

După părerea mea, cel mai bine este să începeți cu nativ și apoi, dacă doriți cu adevărat, să stăpâniți unul sau mai multe instrumente multiplatforme. Singura excepție poate fi dezvoltarea jocurilor, deoarece acestea sunt scrise în principal în Unity, iar acesta este un motor multiplatform.

Dacă vorbim despre avantajele dezvoltării native, atunci pentru un programator înseamnă mai puține obstacole și un număr mai mare de instrumente diferite cu care să lucrezi. El va avea, de asemenea, mai multe surse de informații pentru a rezolva probleme complexe care apar în procesul de creare a unei aplicații - nu este un secret că pentru dezvoltarea nativă există de multe ori mai multe sfaturi și trucuri pe Internet decât pentru dezvoltarea multiplatformă.

Pentru utilizatorul final, dezvoltarea nativă înseamnă că aplicația va avea interfețe și modele de comportament familiare, previzibile - cu condiția ca aplicația să fie scrisă conform tuturor ghidurilor.

Este posibil ca o aplicație multiplatformă să nu fie întotdeauna capabilă să respecte pe deplin liniile directoare ale ambelor platforme, iar acest lucru poate crea dificultăți suplimentare pentru dezvoltator și utilizator. Cel mai simplu exemplu- situația cu butonul „Înapoi”: în Android este prezent pe aproape toate ecranele, în timp ce în iOS nu este. Dacă realizați o aplicație multiplatformă fără acest buton, unii utilizatori de Android pot experimenta disconfort.

De asemenea, merită menționate diferențele dintre costurile de dezvoltare. Dacă proiectul nu este complex, atunci alegerea dezvoltării pe mai multe platforme vă permite să vă economisiți bugetul, deoarece, de fapt, nu dezvoltați produse separate pentru diferite platforme, ci una pentru toți. Dar dacă proiectul crește, atunci cântarul începe să se încline în cealaltă direcție, iar dezvoltarea nativă se poate dovedi a fi mai profitabilă.

Când vine vorba de viteza de aplicare, produsele multiplatformă sunt mai lente. De exemplu, cele bazate pe tehnologii web au un browser ca strat, care încetinește semnificativ aplicația.

Promovați retrogradarea

Alegerea unei abordări multi-platformă sau nativă depinde de fapt de doi factori: natura dezvoltării mobile pe care doriți să o faceți personal sau solicitarea angajatorilor cu care sunteți interesat să colaborați. Deci, de exemplu, dacă te uiți la Upwork (o platformă pentru găsirea de specialiști la distanță pentru proiecte și sarcini), vei observa o preponderență clară a ofertelor în direcția Xamarin și React Native. Avantajele aici sunt evidente: este ieftin, rapid și vă va permite să implementați proiecte pe toate platformele deodată. Cu toate acestea, dacă luăm în considerare marile companii IT care caută angajați în casă, atunci se pune un accent semnificativ pe dezvoltarea nativă, în ciuda faptului că acest tip necesită mai mult timp și este mai scump.

La compania noastră, acordăm prioritate și alegem dezvoltarea nativă, deoarece le permite designerilor și dezvoltatorilor să creeze un UX/UI mai fluid și mai intuitiv. În plus, dezvoltarea nativă oferă un control mai flexibil asupra funcțiilor sistemului.

Promovați retrogradarea

Dacă vrei să devii un dezvoltator mobil, atunci răspunsul este evident: trebuie să alegi oricare dintre mediile de dezvoltare native și să te bazezi pe Objective-C/Swift pentru iOS sau Java/Kotlin pentru Android. În acest caz, toate capacitățile sistemului sunt la dispoziție, puteți controla aproape fiecare nuanță.

Dacă vrei doar să scrii un program care să funcționeze și pe telefoane, atunci nu trebuie să te gândești prea mult și să alegi ceea ce ești cel mai pasionat sau în care ai o experiență notabilă: C++, React Native, Xamarin sau cinci sute de mii de cadre JS pentru dezvoltarea multiplatformă. Sau chiar continuați să vă creați propriile site-uri web [responsive].

Recunosc, sunt destul de sceptic cu privire la întreaga idee a dezvoltării multiplatforme pe platforme la fel de diferite (și divergente) precum Android și iOS. Niciunul dintre vânzători nu îi place dezvoltatorilor „greșiți” care încearcă să stea pe două scaune în același timp. Toată lumea încearcă să lege programatorii de instrumente și medii și nu se poate aștepta nicio tendință spre convergență în viitorul apropiat. Ce să spun, Apple în această cursă chiar a abandonat OpenGL, cea mai multi-platformă dintre toate bibliotecile după Curl, dar acum au propriul lor Metal, care pare să facă același lucru, doar mai bine și într-o altă limbă.

Pe de altă parte, de foarte multe ori dezvoltarea mobilă înseamnă crearea a două aplicații identice pentru un serviciu de rețea. Clienții nu sunt întotdeauna dispuși să plătească pentru două produse care arată complet indistincte, așa că cererea de tehnologii de dezvoltare multiplatformă există și, desigur, este destul de mare. De asemenea, programatorii nu se opun la economisirea banilor, mai ales dacă doresc să vândă o aplicație mobilă și nu doresc să învețe Swift/Kotlin, dar JS/C# este deja la îndemână.

Desigur, dezvoltarea multiplatformă aduce cu ea o mulțime de nuanțe neevidente. Toate soluțiile universale sunt nevoite să construiască castele în nisip: fie bazându-se pe soluții tehnologice complexe și fragile (cum ar fi Xamarin), fie pe motoarele JavaScript mobile, precum React Native. În același timp, furnizorii de platforme nici măcar nu se gândesc să accepte vreuna dintre soluții, iar fiecare actualizare a SDK-ului nativ este o mare bătaie de cap pentru orice cadru multiplatform. Ca să nu mai vorbim de caracteristici specifice sistemului precum accesul la cameră, breloc sau chiar o galerie foto banală, pe care toată lumea încearcă să o ocolească cu diferite grade de succes. Dezvoltatorii care aleg calea universală se trezesc ostatici ai cadrului lor și, adesea, dezvoltarea care promitea economii semnificative se transformă într-o luptă cu o greblă.

De asemenea, este obișnuit ca soluțiile multiplatformă să sacrifice ceea ce se numește experiența utilizatorului (UX): multe cadre încearcă să folosească controale cât mai generale posibil pentru ambele sisteme, iar această soluție este aproape întotdeauna la fel de incomodă pentru toată lumea. Sau încetinește. Sau iese în evidență din stilul general. Sau consumă bateria. Continuați singur lista.

Se deosebesc aplicațiile cross-platform, ale căror nuclee sunt scrise la un nivel scăzut, cât mai comune pentru toate sistemele de operare: în limbaje precum C/C++. În acest caz, se obișnuiește să se generalizeze utilizarea codului care servește logica de afaceri, iar interfața este scrisă pentru fiecare platformă separat. În mod ideal, ar fi evitată duplicarea unei părți critice a aplicației, menținând în același timp o experiență de utilizator specifică platformei. Cu toate acestea, în viața reală totul este mai complicat. De exemplu, Dropbox a încercat să trăiască cu un kernel de nivel scăzut timp de câțiva ani la rând, dar în cele din urmă au renunțat din mai multe motive, iar acum sunt mulțumiți de aplicațiile platformei native. Pe cei interesați îi trimit la articolul lor interesant pe această temă.

În opinia mea, economiile la cadrele multiplatforme sunt întotdeauna iluzorii. Probabil, în unele proiecte banale, în care aplicația este doar o versiune a site-ului principal, super-optimizată pentru mobil, demersul generalizat funcționează. În alte cazuri, riscați să repetați soarta Dropbox. Sfatul meu este, dacă vrei să fii dezvoltator de dispozitive mobile, depune eforturi pentru a învăța platforma. Ei vor plăti întotdeauna, chiar dacă trebuie să participați la un proiect multiplatform.

Promovați retrogradarea

, dezvoltator de software senior la Accenture Tver Technology Center

Piața aplicațiilor mobile se dezvoltă activ, iar gama de tehnologii pentru dezvoltarea lor crește în mod corespunzător. Există destul de multe instrumente pe care le puteți folosi.

Pentru dezvoltarea nativă pe Platforma Android Există Java sau un wrapper peste JVM - Kotlin. Pentru iOS, puteți utiliza Objective-C sau învelișul său - Swift. Toate acestea sunt limbaje OOP care au moștenit mult de la Smalltalk și C.

Pentru dezvoltarea multiplatformă, ei folosesc în prezent Flutter de la Google, pentru care va trebui să-l cunoașteți pe Dart. Sau React Native de pe Facebook.

Pentru un dezvoltator de telefonie mobilă începător, factorul determinant va fi cel mai probabil experiența lui trecută și cunoștințele lingvistice. Dacă setul său de instrumente se bazează pe Java, el va putea explora lumea dezvoltării mobile mult mai rapid prin intermediul platformei Android, folosind același Java sau Kotlin.

În același timp, dezvoltarea Objective-C pentru iOS a luat foarte mult de la Smalltalk, precum Java, așa că dacă doriți, puteți face o alegere în favoarea iOS. Dar merită să luați în considerare faptul că dezvoltarea pentru Android poate avea loc pe Windows sau Linux, dar iOS necesită MacOS X. Dar pentru un dezvoltator JavaScript care cunoaște React, React Native este, evident, cea mai rapidă cale. La fel ca pentru dezvoltatorii Dart, alegerea va fi în favoarea lui Flutter.

După ce un dezvoltator începător își face o idee despre ce este dezvoltarea mobilă și care sunt avantajele și dezavantajele căii alese, el va decide singur dacă să lucreze cu o singură abordare sau să rezolve probleme folosind soluții multiplatforme.

Această abordare are avantajele sale: metoda multiplatformă face posibilă lansarea unui proiect într-un mediu productiv puțin mai rapid, folosind mai puține resurse. În plus, este mai ușor de întreținut. Dar are și dezavantaje evidente atât pentru dezvoltator, cât și pentru utilizator. De exemplu, un dezvoltator nu trebuie să cunoască tehnologiile native, dar trebuie să se țină cont de ghidurile platformei, deoarece o aplicație scrisă conform ghidurilor iOS va cauza dificultăți utilizatorilor de Android și invers.

Aplicațiile multiplatforme nu pot atinge același nivel de integrare a dispozitivelor ca și cele native. Adică, dacă aplicația se referă la interacțiunea cu un dispozitiv, de exemplu cu o cameră, un calendar sau utilizarea puterii de calcul a dispozitivului, atunci este mai ușor să realizați acest lucru folosind o abordare nativă și va fi mai rapid și mai mult productiv.

Atunci când dezvoltă o aplicație multiplatformă, specialiștii țin cont de capacitățile cadrului, care impune restricții. De asemenea, merită luat în considerare faptul că pentru a dezvolta un produs folosind tehnologii native sunt necesari specialiști pentru fiecare platformă.

Dacă lucrați ca freelancer sau aveți un obiectiv de a acoperi numărul maxim de dispozitive cu resurse minime, concentrați-vă pe dezvoltarea multiplatformă dacă vizați soluții mobile sau lucrând ca dezvoltator front-end.

Care sunt principalele avantaje și dezavantaje ale dezvoltării mobile native și cross-platform? Dezvoltarea nativă în sine este costisitoare, deoarece compania trebuie să investească în două echipe - iOS și Android. Pentru aplicații simple, viteza de dezvoltare pe Flutter / React Native este mai mare.

Dar plusul este că infrastructura a fost deja formată și este de înțeles. Aveți acces la orice resurse ale dispozitivului și puteți dezvolta sub ceas inteligent, mașini și multe altele.

Dezvoltarea pe mai multe platforme este, de asemenea, un lucru grozav. Dar nu este încă foarte dezvoltat pe piața muncii IT din Rusia. Pe degete îi poți număra pe specialiștii inteligenți. Infrastructura-cadru este tânără, dar situația se schimbă treptat în bine. Această dezvoltare face posibilă scrierea pentru mai multe dispozitive simultan. Chiar dacă scrii în Flutter, de exemplu, se integrează ușor cu codul nativ.

Promovați retrogradarea

Dezvoltarea pe mai multe platforme vizează rezultate rapide și economii semnificative de buget - scriem un singur cod pentru toate dispozitivele. Domeniul său de aplicare este fie o soluție pentru uz intern, în care utilizarea produsului nu este atât de importantă, iar funcționalitatea joacă un rol dominant, fie crearea unui proiect „pilot” rapid, atunci când clientul trebuie să arate principiul sau ideea aplicației. În plus, dacă nu există o înțelegere precisă a dispozitivului sistem de operare se va uita la prototipul dvs., dezvoltarea multiplatformă este calea de ieșire. Cu toate acestea, trebuie să înțelegeți dinainte că toate dispozitivele au arhitecturi diferite, așa că este aproape imposibil din punct de vedere fizic să rulați o aplicație de înaltă calitate folosind doar codul multiplatform. Scenariile complexe vor necesita scrierea codului nativ. În plus, datorită naturii sale specifice, dezvoltarea multiplatformă implică costuri care nu permit aplicației să fie cât mai eficientă. Acest lucru este de înțeles în acest caz, codul intermediar cross-platform trebuie tradus pentru fiecare dintre platforme, ceea ce face aplicația mai „grea” datorită faptului că, pe lângă codul funcțional, conține mediul său de execuție.

Mai dati-mi o parere

Totul este clar, arată-ți concluziile

Deci, ce abordare de dezvoltare ar trebui să luați?

Totul depinde de sarcină. Dacă trebuie să scrieți un prototip de aplicație pentru mai multe platforme sau versiunea mobilă site-ul, apoi vă puteți uita la cadre multiplatforme. Cu ajutorul lor, cel mai probabil vei scrie o aplicație mai rapid decât cu dezvoltarea nativă, mai ales dacă lucrezi pe un cadru similar instrumentului tău obișnuit, precum React Native.

Pe de altă parte, versatilitatea aplicațiilor cross-platform trebuie compensată cu ceva. Undeva apare un element de interfață „non-nativ”, undeva interacțiunea cu sistemul este mai proastă, undeva viteza de lucru scade etc. În ciuda faptului că dezvoltarea nativă necesită mai multe resurse, multe companii îl preferă deoarece Rezultatul este un produs stabil și cu aspect nativ.

În acest sens, dacă abia începi în dezvoltarea mobilă, ar fi mai bine să începi mai întâi cu dezvoltarea nativă. Puteți găsi mai multe informații despre acesta pe Internet, veți obține o înțelegere mai profundă a capacităților platformei și nu veți fi împiedicat de anumite nuanțe de dezvoltare multiplatformă. Mai mult, dacă decideți să vă implicați în dezvoltarea multiplatformă în viitor, cunoștințele acumulate cu siguranță nu vă vor răni.

Vă reamintim că puteți adresa întrebarea dumneavoastră experților, iar noi vom colecta răspunsuri la aceasta dacă se va dovedi a fi interesantă. Întrebările care au fost deja puse pot fi găsite în lista de probleme. Dacă doriți să vă alăturați experților și să trimiteți un răspuns de la compania dvs. sau de la dvs., atunci scrieți la, vă vom spune cum să faceți acest lucru.

Dezvoltarea multiplatformă vă permite să creați o aplicație mobilă care va funcționa simultan în iOS și Android. Aceasta este o alternativă ieftină la crearea unei aplicații pentru fiecare sistem de operare separat.

Caracteristici ale dezvoltării multiplatforme

Dezvoltarea unei aplicații pentru diferite platforme este bună și rea în același timp. Bine, pentru că se poate face mai rapid și mai ieftin decât mai multe aplicații pentru fiecare sistem de operare. Și acest lucru este rău, deoarece compromisul afectează funcționarea aplicației.

Aceste caracteristici trebuie luate în considerare înainte de a începe proiectul:

• Într-un mediu multiplatformă, codul este scris o singură dată. Pentru ca aplicația să funcționeze pe alt sistem de operare, codul este tradus într-un alt limbaj de programare. Timpul și banii cheltuiți pentru dezvoltare sunt de 1,5 ori mai puțini.
• Este posibil ca aplicațiile să nu funcționeze corect.În dezvoltarea multiplatformă, este imposibil să se țină cont de toate nuanțele de lucru cu arhitectura fiecărui sistem de operare, astfel încât aplicațiile pot rula mai lent decât cele dezvoltate special pentru iOS sau Android.
• Interfața și cerințele de proiectare pentru elemente variază între sistemele de operare.. De exemplu, iOS nu are un buton Înapoi, așa cum are Android. La dezvoltarea unui design unificat, acest punct trebuie luat în considerare: în iOS, butonul fie va rămâne, dar nu va funcționa, fie va trebui să fie tăiat manual, ceea ce înseamnă lucru suplimentar cu codul.

Majoritatea erorilor la migrarea de la o platformă la alta pot fi rezolvate manual, dar este imposibil să rezolvi complet problemele de adaptare la un sistem de operare „non-nativ”.

Deci, dezvoltarea multiplatformă este proastă?

Nu, dezvoltarea multiplatformă este bine atâta timp cât nu cereți de la ea mai mult decât poate oferi.

Această opțiune poate fi selectată în următoarele cazuri:

• Acoperă toate sistemele de operare cu un buget limitat. Dacă publicul țintă utilizează în mod activ iOS sau Android, puteți începe cu o aplicație nativă pentru un sistem de operare. Dacă acoperirea maximă este importantă imediat, este mai bine să alegeți o opțiune multiplatformă.
• Verificați nișa. Dacă există o idee promițătoare, dar nu ești sigur că va funcționa, investirea imediată a unui buget mare în dezvoltare este riscantă. Este logic să începeți cu dezvoltarea multiplatformă, să studiați reacțiile utilizatorilor și să luați decizii strategice pe baza acestui lucru.
• Aplicația nu folosește animații complexe și nu efectuează calcule. Aceste operațiuni încarcă serios dispozitivul, iar aplicația multiplatformă nu este optimizată pentru utilizarea deplină a resurselor unei anumite platforme.
• Aplicația folosește doar funcțiile de bază ale dispozitivului. Afișați informații, încărcați fișiere, utilizați geolocalizarea, plasați o comandă - aplicația multiplatformă se poate ocupa de toate acestea. Este necesară o integrare mai profundă a capabilităților dispozitivului - va trebui să alegeți dezvoltarea nativă.
• Aplicație corporativă pentru angajați. Dacă aplicația este dezvoltată pentru sarcini interne înguste și oamenii vor lucra cu ea prin intermediul gadgeturilor personale, o aplicație multiplatformă va fi cea mai bună opțiune.

Nu există un răspuns universal la întrebarea dacă soluțiile multiplatforme pot fi utilizate pentru proiectul dvs. Completați formularul de mai jos: vă vom studia proiectul și vom selecta cea mai buna varianta pentru implementarea acestuia.

Aplicații multiplatforme – a fi sau a nu fi? Întrebarea nu este ușoară, deoarece fiecare afacere are propriile obiective și cerințe pentru aplicațiile mobile. Dar astăzi ne vom da seama cu siguranță care dezvoltare este potrivită pentru tine.

Ce sunt aplicațiile cross-platform?

Aplicațiile cross-platform sunt aplicații care sunt dezvoltate și apoi rulează atât pe Android, cât și pe iOS. Esența dezvoltării este că cod sursă Aplicația este tradusă în nativ, adică ușor de înțeles pentru un anumit dispozitiv mobil. Drept urmare, programul poate interacționa cu sistemul de operare instalat pe acesta.

Să vă reamintim: aplicațiile native, spre deosebire de cele multiplatforme, sunt scrise pentru un anumit sistem de operare.

Avantajele dezvoltării pe mai multe platforme

• extinderea bazei de utilizatori datorită apariției aplicației în mai multe magazine simultan;
• Codul sursă unic elimină necesitatea de a angaja mai mulți dezvoltatori pentru fiecare platformă;
• 75% din baza de cod a unei aplicații multiplatformă poate fi reutilizată, adaptându-l pentru proiecte noi.

Dezavantajele dezvoltării multiplatforme

1. Dependență puternică de un dispozitiv mobil

Aplicațiile pe mai multe platforme nu funcționează de obicei offline. Prin urmare, capacitățile lor depind în mare măsură de faptul că utilizatorul are o conexiune stabilă la Internet. Versiunea sistemului de operare și modelul dispozitivului sunt, de asemenea, importante. O aplicație multiplatformă este aproape garantată pentru a reduce performanța unui dispozitiv mai vechi de unul sau doi ani. În timp ce o aplicație nativă va funcționa stabil chiar și pe un gadget antic cu firmware învechit. Deci, dacă nu doriți ca clienții dvs. să citească recenzii supărate despre modul în care aplicația dvs. a „terminat” în cele din urmă smartphone-ul cuiva, alegeți dezvoltarea nativă.

2. Interfață de utilizator neprietenoasă

Utilizatorii devin atât de obișnuiți cu aspectul și funcționalitatea gadgeturilor lor încât se așteaptă la maxim de răspuns de la aplicațiile instalate pe ele. Vor să fie siguri că fiecare buton va fi la locul său potrivit, că pagina se va derula la viteza optimă pentru ei și că orice acțiune pe care o întreprind va fi urmată de un răspuns imediat. Aplicațiile cross-platform au de obicei dificultăți de adaptare la dispozitiv și nu se pot lăuda cu performanță.

Problema este că pentru dezvoltarea multiplatformă nu există linii directoare - standarde de dezvoltare de la creatorii sistemului de operare. Prin urmare, o aplicație multiplatformă făcută „pentru Android” nu va fi convenabilă pentru un utilizator iOS și invers. Puteți, desigur, să creați designuri separate pentru fiecare platformă, dar în ceea ce privește costurile forței de muncă, acest lucru va fi egal cu crearea a două aplicații diferite, deși în aceeași limbă.

3. Lupta pentru primatul între instrumentele de dezvoltare

Pe piața soluțiilor de dezvoltare multiplatformă, concurența devine din ce în ce mai dură în fiecare zi. Până acum, React Native și Xamarin sunt cele mai populare printre dezvoltatori, dar ar putea fi depășiți, de exemplu, de Vue Native. În acest caz, foștii lideri ai cursei își vor pierde cel mai important avantaj - suportul de cod operațional. Și acest lucru se poate întâmpla cu orice instrument multiplatform.

Dezvoltarea nativă nu se teme de o astfel de problemă. Introducerea de noi instrumente are loc treptat, iar cunoașterea mai multor limbaje de programare, care este obligatorie pentru un specialist, îi va permite să înțeleagă rapid toate inovațiile. În plus, există comunități profesionale uriașe în jurul fiecărui sistem de operare, în urma cărora orice dificultate care apare este rezolvată prin căutarea unei probleme similare pe forumuri, unde mii de oameni sunt gata să sugereze și să ajute la rezolvarea acesteia.

Care aplicație este potrivită pentru afacerea dvs.?

Înainte de a răspunde la această întrebare, este esențial să-ți analizezi afacerea. Segmente de consumatori, valoarea resurselor de timp și bani, profunzimea dorită de integrare a aplicației cu dispozitivele utilizatorului, plus obiective pe termen lung clar definite - minimul de care va depinde alegerea dvs. Dar vă vom face mai ușor dacă răspundeți la întrebările relevante chiar acum.

1. Ce folosește publicul tău?

Dacă știți că raportul dintre utilizatorii iOS și Android dintre clienții dvs. este aproape de 50/50, alegeți dezvoltarea nativă. Acest lucru va arăta că respectați nevoile tuturor clienților dvs. în mod egal, indiferent de nivelul veniturilor acestora.

Relația dintre alegeri dispozitiv mobil iar nivelul de solvabilitate a fost confirmat din nou de App Annie. Ca rezultat al unui studiu al numărului de descărcări și vânzări de aplicații mobile în Google PlayŞi App Storeîn primul trimestru al anului 2018, s-a dovedit că utilizatorii de smartphone-uri Android au descărcat cu 135% mai multe aplicații decât vizitatorii magazinului iOS. În același timp, App Store a adus proprietarilor săi venituri cu 85% mai multe decât Google Play.

Calea spre succes este evidentă: joci pe două terenuri deodată. Mai exact, în două magazine. Doar calculați în care dintre ele ar trebui să apară prima aplicație. Desigur, cu excepția cazului în care o lansare simultană face parte din strategia ta digitală).

2. Cât timp de dezvoltare aveți?

Costurile financiare ale proiectului depind de răspunsul la această întrebare. Cert este că din punct de vedere al timpului petrecut cu dezvoltarea, o aplicație cross-platform pare a fi doar o soluție mai profitabilă. De fapt, adaptarea acestuia la platforme poate dura aproape la fel de mult ca crearea a două aplicații native, deoarece dezvoltatorii vor trebui să scrie bucăți suplimentare de cod pentru a aborda zonele cu probleme.

Cu o aplicație nativă cu siguranță nu vor exista astfel de probleme, ceea ce este foarte important pentru menținerea unui public care este extrem de intolerant la erori și bug-uri. Conform statisticilor Compuware, 79% dintre utilizatori sunt gata să repornească o aplicație dacă aceasta nu a funcționat corect la prima lansare, dar doar 16% sunt de acord să-i mai acorde o șansă. Alții vor dezinstala, cel mai probabil, pur și simplu programul.

3. Ce caracteristici ale dispozitivului intenționați să utilizați?

Am vorbit deja despre faptul că numai aplicațiile native sunt capabile să reproducă grafică grea rapid și fără pierderi de calitate. Dar avantajele tehnice ale dezvoltării native nu se limitează la asta. Ca exemplu putem lua aplicația Facebook. Datorită lansării versiunilor separate pentru Android și iOS, defilarea a devenit mai fluidă, timpii de încărcare a imaginilor au fost reduse și toate problemele de cache au fost rezolvate.

Mai mult, aplicațiile native au acces direct la toate serviciile dispozitivului, permițându-vă să obțineți informații despre geolocalizarea utilizatorului sau lista de contacte a acestuia. Aplicațiile multiplatforme trebuie să utilizeze pluginuri native speciale, care afectează negativ viteza de transfer de date și supraîncărcările RAM dispozitive.

4. La ce rezultate te străduiești?

O strategie digitală este o listă de obiective pe care compania ta le poate atinge folosind instrumente digitale. Alegerea acestuia din urmă depinde în mare măsură de beneficiile pe care doriți să le obțineți în final.

Defalcați procesul de la idee la rezultat punct cu punct, ținând cont de toate resursele disponibile. Descoperirile pot fi cele mai neașteptate.

De exemplu, este posibil să descoperiți că este prea costisitor să transformați site-ul dvs. responsive, care este încărcat cu funcții și elemente interactive, într-o aplicație multiplatformă așa cum v-ați dorit inițial. Sau, în sfârșit, asigurați-vă că un site mobil pierde întotdeauna în fața unei aplicații mobile, la fel cum dezvoltarea multiplatformă pierde în fața dezvoltării native. Și printre motive le veți găsi pe cele pe care le-am descris mai sus.

Concluzie: o aplicație multiplatformă este benefică doar într-un singur caz - creați o versiune demo a aplicației, limitată în timp, bani și specialiști înalt specializați. În toate celelalte cazuri, o aplicație nativă vă va oferi de multe ori mai multe avantaje, deoarece este un nivel de dezvoltare calitativ diferit.

Smartphone-urile continuă să câștige din ce în ce mai mult spațiu la soare, nu doar ca instrument de consum de fotografii cu pisici și videoclipuri XXX, ci și ca instrument de lucru. Prin urmare, cererea de dezvoltare mobilă este în creștere. Este în general acceptat că forța de muncă și cool sunt Objective-C/Swift pentru iOS și Java/Kotlin pentru Android. Fără îndoială, este o muncă grea și mișto, dar există un număr mare de scenarii reale în care utilizarea cadrelor multiplatforme este mai de preferat în comparație cu instrumentele native.

Unii dezvoltatori se așteaptă ca cadrele multiplatforme să le rezolve toate problemele vieții, în timp ce alții le sunt ostili. Ambele „tabere în război” au propriile lor concepții greșite cauzate de lipsa de înțelegere a modului și a ceea ce funcționează. Acest lucru adaugă combustibil focului, deoarece emoțiile sunt folosite în loc de argumente tehnice.

De asemenea, printre dezvoltatori, în special începători, există multe mituri despre cadrele mobile multiplatforme. În articolul nostru le vom analiza pe cele mai populare dintre ele. Dar mai întâi, să privim dezvoltarea mobilă prin ochii unei afaceri care furnizează bani pentru întregul blackjack IT.

De ce avem nevoie de instrumente multiplatforme?

Din punct de vedere istoric, pe piața calculatoarelor a existat întotdeauna concurență, iar fiecare producător a furnizat setul optim de așa-numite instrumente native pentru dezvoltarea aplicațiilor pentru sistemele și dispozitivele lor de operare.

Instrumente native = furnizate de proprietarul ecosistemului.

Toate celelalte semne de „nativitate” sunt SECUNDARE - comportament și interfața aplicației, acces la capabilitățile sistemului de operare, performanță etc.

În plus, aproape întotdeauna s-a dovedit că instrumentele native sunt incompatibile între ele nu numai la nivel de limbaje de dezvoltare, convenții și arhitecturi acceptate, ci și la nivelul mecanismelor de lucru cu sistemul de operare și bibliotecile. Ca urmare, pentru a implementa aceiași algoritmi și interfețe, a fost necesar să scrieți o aplicație pentru mai multe medii în diferite limbaje de programare, apoi să o susțineți pe o bază „o comandă pe platformă”. În același timp, posibilitățile și aspect aplicațiile de pe platforme diferite sunt aproape întotdeauna 90% identice. Doar pentru distracție, compară implementarea programelor tale preferate pentru iOS și Android.

Doilea punct important- disponibilitatea cunoștințelor și experienței necesare în cadrul echipei: dacă nu sunt acolo, atunci va dura timp să se antreneze.

Pentru a rezolva ambele probleme, instrumentele de dezvoltare multiplatformă (nu doar mobile) au apărut de mult pe piață, oferind:

• maximizați baza de cod comună într-un singur limbaj de programare, astfel încât produsul să fie mai ușor de dezvoltat și întreținut;
• folosiți competențele și specialiștii existenți pentru a implementa aplicații pe platforme noi.

Deoarece acum există o mulțime de limbaje de programare (și medii) (și specialiști care vorbesc aceste limbaje), există un număr destul de mare de instrumente pentru dezvoltarea multiplatformă. De exemplu, ne vom concentra pe cele populare din zona noastră PhoneGap, Xamarin, React Native și Qt.

Acum putem vorbi despre mituri.

Mitul 1. Magie

Cel mai des întâlnit mit care bântuie mintea dezvoltatorilor începători este legat de credința în super-algoritmi (și super-programatorii care i-au creat) care transformă magic aplicațiile multiplatforme în native. Ceva de genul „conversiei codului JavaScript în Swift și apoi compilarea unei aplicații Swift”. Acest mit este alimentat de dezvoltatorii de instrumente multiplatforme înșiși, promițând ca rezultat crearea de „aplicații native”. Și nu este că cineva minte aici, dar imaginația bogată și neînțelegerea mecanismelor de bază îi determină uneori pe dezvoltatori să se gândească la tehnici șamanice.

Principiul principal care stă la baza soluțiilor multiplatforme este împărțirea codului în două părți:

• multiplatformă, trăind într-un mediu virtual și având acces limitat la capacitățile platformei țintă printr-un pod special;
• nativ, care oferă inițializarea aplicației, gestionarea ciclului de viață al obiectelor cheie și are acces deplin la sistem API.

Pentru a conecta lumea „nativă” și lumea „cross-platformă”, este necesar să folosiți un special pod, el este cel care determină capacitățile și limitările cadrelor multiplatforme.

Când utilizați o punte, performanța este întotdeauna redusă datorită conversiei datelor între „lumi”, precum și conversiei apelurilor și bibliotecilor API.

Deci, toate aplicațiile multiplatforme trebuie să aibă o parte nativă, altfel sistemul de operare pur și simplu nu le va putea rula. Deci, să aruncăm o privire mai atentă la ce API-uri și mecanisme de sistem sunt furnizate de iOS, Android și Windows înșiși. Să trecem la următorul mit.

Mitul 2. Nu nativ!

Deci, avem o parte multiplatformă a aplicației care trăiește într-un mediu virtual și interacționează cu sistemul de operare prin infrastructura cadru și bridge.

Toate sistemele de operare: iOS, Android și Windows UWP oferă acces la următoarele subsisteme (seturi de API-uri de sistem):

• WebView (browser web integrat în aplicație) este utilizat în aplicații hibride bazat pe PhoneGap și acționează de fapt ca un mediu de rulare pentru un site web local;
• Motoarele JavaScript sunt utilizate în React Native și analogii pentru executarea rapidă a codului JS și schimbul de date între Native și JS;
• OpenGL ES (sau DirectX) este folosit în motoarele de jocuri și aplicațiile bazate pe Qt/QML sau analogi pentru redarea interfeței;
• Subsistemul UI este responsabil pentru interfața de utilizator nativă a aplicației, care este relevantă pentru React Native și Xamarin.

Aplicațiile multiplatforme au o parte nativă și același acces complet la API-urile de sistem ca și aplicațiile native. Diferența este că metoda de sistem este apelată prin intermediul podului și al infrastructurii cadru:

WebView- aplicația locuiește în browserul său web, similar unui site web de o pagină. Nu există acces la controalele native (butoane, liste etc.), totul se bazează pe HTML/CSS/JavaScript. Pe de altă parte, un dezvoltator web se va simți ca un pește din apă.

Motoare JavaScript a devenit popular relativ recent, deoarece un mecanism similar a fost adăugat la iOS doar în versiunea 7.0. Una dintre caracteristicile care merită luate în considerare este necesitatea de a serializa structurile complexe de date transferate între JavaScript și mediile native în JSON. Pentru a descrie pe scurt această clasă de soluții, codul JS care controlează aplicația nativă este executat în mediul JavaScript.

OpenGL ES și DirectX sunt subsisteme de nivel scăzut și sunt folosite pentru a reda interfața cu utilizatorul în jocuri și, de exemplu, Qt/QML. Adică, atunci când folosesc OpenGL/DirectX, dezvoltatorii înșiși desenează controale și animații, care pot fi similare doar cu cele native. Pe de altă parte, este un subsistem de nivel scăzut, cu performanțe foarte ridicate, motiv pentru care este folosit și în motoarele de jocuri multiplatforme.

Toate aplicațiile multiplatformă au o parte nativă și, prin urmare, potențial același acces complet la API-urile de sistem ca și cele native. De asemenea, aplicațiile multiplatformă sunt construite și împachetate cu instrumente native în pachete de instalare native. Întrebarea cheie este cum este organizată interacțiunea dintre partea multi-platformă și cea nativă. De exemplu, în WebView sau folosind Open GL ES / DirectX nu există nicio modalitate de a crea o interfață de utilizator cu un aspect complet nativ, dar în același timp există acces deplin la GPS, Notificări Push și alte funcționalități. Și codul în JavaScript sau C# poate controla destul de liber aplicația nativă și comportamentul acesteia, oferind un aspect complet nativ.

Pentru a rezuma, da, este „non-native” din punctul de vedere al instrumentelor de dezvoltare folosite (nu de la Apple, Google). Dar o aplicație poate fi complet nativă în ceea ce privește accesul la API-urile de sistem și poate oferi un aspect complet nativ. Și trecem la următorul mit.

Mitul 3. O cârjă pe o cârjă

Aici merită să înțelegeți că API-urile native nu sunt considerate cârje în mod implicit (deși aici există opinii diferite), așa că toată indignarea este îndreptată către partea multiplatformă. Evident, mediul de execuție (de exemplu, WebView, motor JavaScript sau Mono) este, de asemenea, greu de numit cârjă - soluții mature mature cu o istorie lungă.

Se pare că cârja este modul în care partea multiplatformă se integrează cu cea nativă. Pentru a înțelege mai bine cum funcționează diferitele cadre, folosind exemplul PhoneGap, Xamarin, Qt și React Native, ne vom uita la acele mecanisme ale sistemului de operare care sunt utilizate pentru a lega părțile multiplatforme și „native”.

Vom începe cu PhoneGap. Mai jos este arhitectura de nivel superior a unei aplicații bazată pe acest cadru.

O aplicație pe PhoneGap este de fapt o aplicație nativă care afișează un WebView ca singur control UI. Prin ea are loc interacțiunea cu partea nativă. Toate WebView-urile standard din iOS, Android și Windows UWP acceptă posibilitatea de a adăuga propriile dvs. handlere native pentru proprietățile și metodele JS. În același timp, codul JS trăiește în propriul său mediu izolat și nu știe nimic despre partea nativă - pur și simplu trage metodele JS necesare sau modifică proprietățile JS necesare. Totul se află în interiorul web DOM standard, la care pur și simplu se adaugă elemente noi asociate cu implementarea nativă.

Când creează aplicații în React Native, dezvoltatorul va trebui aproape întotdeauna să implementeze partea nativă în Objective-C, Java sau C#, iar gestionarea aplicației native în sine va veni din JavaScript. De fapt, motorul JavaScript este un element WebView care este disponibil separat. Interacțiunea are loc prin aceeași punte JS ca și în cazul PhoneGap. Cu toate acestea, în React Native, codul JS nu controlează arborele web DOM, ci aplicația nativă.

Vă rugăm să rețineți că, din cauza limitărilor iOS (nu există nicio modalitate de a implementa JIT), codul JavaScript este interpretat din mers, mai degrabă decât compilat. În general, acest lucru nu are un impact semnificativ asupra performanței în aplicații reale, dar merită amintit.

Acum să ne uităm la Xamarin.iOS și Xamarin.Android clasic, deoarece Xamarin.Forms (care acceptă Windows UWP) este un supliment pentru acestea.

Xamarin folosește biblioteca Mono pentru a interacționa cu sistemul de operare țintă, ceea ce vă permite să apelați codul nativ folosind mecanismul P/Invoke. De asemenea, este folosit pentru a comunica cu API-urile native în iOS/Android. Adică, pentru toate metodele API native publice, wrapper-urile sunt create în C#, care, la rândul lor, apelează API-uri de sistem. În acest fel, puteți accesa toate API-urile de sistem din aplicația Xamarin.

Și, în sfârșit, să ne uităm la Qt, deoarece există o mulțime de întrebări despre acesta din partea dezvoltatorilor experimentați.

Qt este un „lucru în sine”, acesta are atât avantaje, cât și limitări. Bibliotecile Qt se conectează pur și simplu la API-urile sistemului C++ găsite pe toate sistemele de operare. Mecanismele de nivel scăzut sunt folosite pentru a reda interfața cu utilizatorul, dar a lor proprie motor grafic, susținând stilul nativ. În acest caz, pe Android trebuie să accesați API-ul Java printr-o punte specială (punte JNI), iar pentru Windows UWP trebuie să utilizați convertorul de apel Open GL ES la DirectX, deoarece Open GL nu este disponibil pentru UWP.

Pentru a rezuma: toate cadrele multiplatforme folosesc capabilități native standard ale sistemelor de operare, sunt mature, sunt în curs de creare echipe experimentateși comunitatea open source cu sprijinul giganților din industria IT. Și, în sfârșit, este timpul pentru „cel mai puternic” argument.

Mitul 4. Încet

Un atu important pe care oamenilor le place să îl folosească în disputele legate de cadrele multiplatforme este performanța scăzută. Din nou, depinde de ce să compari și de ce papagali să numere.

Să ne amintim că particularitatea aplicațiilor multiplatforme este existența paralelă a două lumi conectate printr-un pod:

• PhoneGap: HTML/JS și Java nativ / Objective-C / C#;
• React Native: JS și Native Java / Objective-C / C#;
• Xamarin: mono și nativ Java/Obiective-C;
• Qt: C++ și Java nativ / Objective-C.

Astfel, atunci când comparăm performanța, trebuie să țineți cont de viteza de funcționare:

• parte cross-platform;
• parte nativă;
• pod.

Dacă introduceți într-un motor de căutare, de exemplu, reacţionează nativ față de performanța rapidă, puteți analiza multe teste diferite și multe dintre ele observă că performanța scade brusc odată cu utilizarea activă a podului, inclusiv manipularea activă a interfeței de utilizare din codul multiplatformă. Pentru Xamarin, situația arată la fel - partea multiplatformă este foarte rapidă și comparabilă cu cea nativă în procesarea datelor, dar atunci când se folosește bridge-ul, performanța poate scădea. Qt funcționează în general la nivel C++, care este rapid în sine. Dacă luăm în considerare soluții bazate pe PhoneGap, atunci performanța va depinde în mare măsură de WebView, dar totuși nu ar trebui să schimbați în mod activ interfața de utilizare în codul JavaScript sau să efectuați calcule științifice.

Încet? Da, scăderile de performanță sunt posibile din cauza interacțiunii inepte cu sistemul de operare prin intermediul unui bridge. Cu toate acestea, lumile multiplatforme sunt la fel de rapide ca și cele native.