Interfețe cu utilizatorul iOS: Storyboard-uri vs. NIB-uri vs. Cod personalizat

Aud adesea dezvoltatorii iOS punând o variantă a aceleiași întrebări cheie:

Care este cea mai bună modalitate de a dezvolta o interfață de utilizare în iOS: prin Storyboard-uri, NIB-uri sau cod?

Răspunsurile la această întrebare, în mod explicit sau implicit, tind să presupună că trebuie făcută o alegere care se exclude reciproc, una care este adesea abordată în avans, înainte de dezvoltare.

Sunt de părere că răspunsul ar trebui să ia forma uneia sau mai multor întrebări contrare .

Care este „cea mai bună” mașină?

Permiteți-mi să vă explic cu un exemplu în afara subiectului. Să spunem că vreau să cumpăr o mașină și îți pun o întrebare simplă: „Care este cea mai bună alegere?”

Chiar poți să răspunzi sugerând un model sau chiar o marcă? Nu este probabil, decât dacă sugerezi un Ferrari. În schimb, probabil ai răspunde cu alte câteva întrebări, cum ar fi:

• Care este bugetul tău?
• De câte locuri ai nevoie?
• Îți pasă de consumul de combustibil?
• Ce părere aveți despre mașinile sport?

Este evident că nu există o mașină bună sau rea decât dacă este plasată într-un context adecvat - există doar o mașină bună sau proastă în funcție de nevoi specifice.

Înapoi la iOS UI Design

La fel ca în cazul întrebării noastre privind mașina, întrebarea „Care este cel mai bun mod de a dezvolta o interfață de utilizare iOS” nu are context. Și, în mod surprinzător, răspunsul nu trebuie să fie un caz general.

În linii mari, există trei tipuri de abordări de proiectare a interfeței cu utilizatorul pe care le puteți lua, fiecare cu avantajele și dezavantajele sale, fanii și urătorii săi:

• Storyboard-uri iOS : un instrument vizual pentru aranjarea mai multor vizualizări ale aplicațiilor și tranzițiile dintre ele.
• NIB- uri (sau XIB-uri) : Fiecare fișier NIB corespunde unui singur element de vizualizare și poate fi așezat în Interface Builder, făcându-l și un instrument vizual. Rețineți că numele „NIB” este derivat din extensia fișierului (anterior .nib și acum .xib, deși vechea pronunție a persistat).
• Cod personalizat : adică, fără instrumente GUI, ci mai degrabă, gestionarea tuturor poziționării personalizate, animației etc. în mod programatic.

Niciuna dintre aceste opțiuni nu este universal mai bună decât oricare alta (în ciuda a ceea ce ați putea auzi).

Storyboard-urile, de exemplu, sunt cea mai recentă adăugare la setul de instrumente iOS UI. Mi s-a spus că ei sunt viitorul, că vor înlocui NIB-urile și interfețele de utilizator cu coduri personalizate. Văd Storyboard-urile ca un instrument util, dar nu atât de mult un înlocuitor , cât un complement pentru NIB-uri și cod personalizat. Storyboard-urile sunt alegerea potrivită în unele situații, dar nu în toate.

Mai mult, de ce ar trebui să rămâneți static la o singură opțiune când le puteți utiliza pe toate (în același proiect), alegând mecanismul care se potrivește cel mai bine problemei specifice la îndemână?

Aceasta este o întrebare care poate fi, în opinia mea, generalizată la un nivel superior și al cărei răspuns este clasat foarte bine în lista mea de principii de dezvoltare software: nu există un limbaj, un cadru sau o tehnologie universală care să fie cea mai bună alegere universală pentru fiecare. problema de dezvoltare software. Același lucru este valabil și pentru designul UI iOS.

În acest tutorial de dezvoltare iOS, vom explora fiecare dintre aceste metode și vom introduce cazuri de utilizare în care ar trebui și nu ar trebui să fie folosite, precum și modalități în care pot fi combinate.

Storyboard-uri iOS

Greșeala unui începător clasic este să creeze un singur Storyboard iOS masiv la nivelul întregului proiect. Și eu am făcut această greșeală când am început să lucrez cu Storyboards (probabil pentru că este un traseu tentant de urmat).

După cum sugerează și numele, un Storyboard este un panou cu o poveste de spus . Nu ar trebui să fie folosit pentru a amesteca povești fără legătură într-un singur volum mare. Un storyboard ar trebui să conțină controlere de vizualizare care sunt legate logic între ele, ceea ce nu înseamnă fiecare controler de vizualizare.

De exemplu, este logic să folosiți Storyboard-uri atunci când manipulați:

• Un set de vizualizări pentru autentificare și înregistrare.
• Un flux de introducere a comenzilor în mai mulți pași.
• Un flux asemănător unui vrăjitor (adică, tutorial).
• Un set de detalii principale de vizualizări (de exemplu, liste de profiluri, detalii de profil).

Între timp, ar trebui evitate Storyboard-urile mari, inclusiv Storyboard-urile cu o singură aplicație (cu excepția cazului în care aplicația este relativ simplă). Înainte de a merge mai adânc, să vedem de ce.

Nebunia scenariilor mari iOS

Storyboard-urile mari, în afară de a fi dificil de răsfoit și întreținut, adaugă un strat de complexitate unui mediu de echipă: atunci când mai mulți dezvoltatori lucrează la același fișier storyboard în același timp, conflictele de control sursă sunt inevitabile . Și în timp ce un storyboard este reprezentat intern ca un fișier text (un fișier XML, de fapt), fuzionarea este de obicei netrivială.

Când dezvoltatorii văd codul sursă, îi atribuie un sens semantic. Deci, atunci când se îmbină manual, ei sunt capabili să citească și să înțeleagă ambele părți ale unui conflict și să acționeze în consecință. Un storyboard, în schimb, este un fișier XML gestionat de Xcode, iar semnificația fiecărei linii de cod nu este întotdeauna ușor de înțeles.

Să luăm un exemplu foarte simplu: să presupunem că doi dezvoltatori diferiți schimbă poziția unei UILabel (folosind autolayout), iar acesta din urmă împinge schimbarea lui, producând un conflict ca acesta (observați atributele id -ul conflictuale):

 <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides> <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides>

id -ul în sine nu oferă nicio indicație cu privire la adevărata sa semnificație, așa că nu aveți cu ce să lucrați. Singura soluție semnificativă este alegerea uneia dintre cele două părți ale conflictului și renunțarea la cealaltă. Vor exista efecte secundare? Cine știe? Nu tu.

Pentru a ușura aceste probleme de proiectare a interfeței iOS, abordarea recomandată este utilizarea mai multor storyboard-uri în același proiect.

Când să folosiți Storyboard-urile

Storyboard-urile sunt cel mai bine utilizate cu mai multe controlere de vizualizare interconectate, deoarece simplificarea lor majoră este în tranziția între controlere de vizualizare. Într-o anumită măsură, ele pot fi considerate ca o compoziție de NIB-uri cu fluxuri vizuale și funcționale între controlerele de vizualizare.

Pe lângă facilitarea fluxului de navigare, un alt avantaj distinct este că elimină codul standard necesar pentru a deschide, împinge, prezenta și închide controlerele de vizualizare. În plus, controlerele de vizualizare sunt alocate automat, deci nu este nevoie să alloc și să init manual.

În cele din urmă, în timp ce Storyboard-urile sunt cel mai bine folosite pentru scenarii care implică mai multe controlere de vizualizare, este, de asemenea, defensibil să folosiți un Storyboard atunci când lucrați cu un singur controler de vizualizare a tabelului din trei motive:

• Capacitatea de a proiecta prototipuri de celule de masă la locul lor ajută la menținerea pieselor împreună.
• Mai multe șabloane de celule pot fi proiectate în interiorul controlerului de vizualizare a tabelului părinte.
• Este posibil să creați vizualizări statice de tabel (o adăugare mult așteptată care, din păcate, este disponibilă numai în Storyboard-uri).

S-ar putea argumenta că mai multe șabloane de celule pot fi proiectate și folosind NIB-uri. De fapt, aceasta este doar o chestiune de preferință: unii dezvoltatori preferă să aibă totul într-un singur loc, în timp ce altora nu le pasă.

Când să nu folosiți Storyboard-urile iOS

Câteva cazuri:

• Vederea are un aspect complicat sau dinamic, cel mai bine implementat cu cod.
• Vizualizarea este deja implementată cu NIB-uri sau cod.

În aceste cazuri, putem fie să părăsim vizualizarea din Storyboard, fie să o încorporam într-un controler de vizualizare. Primul rupe fluxul vizual al Storyboard-ului, dar nu are implicații funcționale sau de dezvoltare negative. Acesta din urmă păstrează acest flux vizual, dar necesită eforturi suplimentare de dezvoltare, deoarece vizualizarea nu este integrată în controlerul de vizualizare: este doar încorporat ca componentă, prin urmare controlerul de vizualizare trebuie să interacționeze cu vizualizarea mai degrabă decât să o implementeze.

Pro și contra generale

Acum că avem o idee despre când Storyboard-urile sunt utile în designul UI iOS și înainte de a trece la NIB-uri în acest tutorial, să trecem prin avantajele și dezavantajele lor generale.

Pro: Performanță

În mod intuitiv, puteți presupune că atunci când un Storyboard este încărcat, toate controlerele sale de vizualizare sunt instanțiate imediat. Din fericire, aceasta este doar o abstractizare și nu este adevărată pentru implementarea reală: în schimb, este creat doar controlerul de vizualizare inițial, dacă există. Celelalte controlere de vizualizare sunt instanțiate dinamic, fie atunci când se execută o continuare, fie manual din cod.

Pro: Prototipuri

Storyboard-urile simplifică prototiparea și simularea interfețelor și fluxului utilizatorului. De fapt, o aplicație prototip complet funcțională, cu vizualizări și navigare, poate fi implementată cu ușurință folosind Storyboard-uri și doar câteva linii de cod.

Contra: Reutilizabilitate

Când vine vorba de mutare sau copiere, Storyboard-urile iOS sunt prost poziționate. Un Storyboard trebuie mutat împreună cu toate controlerele sale de vizualizare dependente. Cu alte cuvinte, un singur controler de vizualizare nu poate fi extras individual și reutilizat în altă parte ca o singură entitate independentă; depinde de restul Storyboard-ului pentru a funcționa.

Contra: Fluxul de date

Datele trebuie adesea transmise între controlerele de vizualizare atunci când o aplicație trece. Cu toate acestea, fluxul vizual al Storyboard-ului este întrerupt în acest caz, deoarece nu există nicio urmă că acest lucru se întâmplă în Interface Builder. Storyboard-urile se ocupă de gestionarea fluxului dintre controlerele de vizualizare, dar nu și de fluxul de date. Deci, controlerul de destinație trebuie configurat cu cod, suprascriind experiența vizuală.

În astfel de cazuri, trebuie să ne bazăm pe un prepareForSegue:sender , cu un schelet if/else-if ca acesta:

 - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier isEqualToString@"segue_name_1"]) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier isEqualToString@"segue_name_2"]) { ... } else if ... }

Consider că această abordare este predispusă la erori și inutil de verboroasă.

NIB-uri

NIB-urile sunt modalitatea veche (mai veche) de a realiza proiectarea interfeței iOS.

În acest caz, „vechi” nu înseamnă „rău”, „învechit” sau „depreciat”. De fapt, este important să înțelegeți că Storyboard-urile iOS nu sunt un înlocuitor universal pentru NIB; ele simplifică doar implementarea UI în unele cazuri.

Cu NIB-uri, poate fi proiectată orice vizualizare arbitrară, pe care dezvoltatorul o poate atașa apoi la un controler de vizualizare după cum este necesar.

Dacă aplicăm design orientat pe obiecte la interfețele noastre de utilizare, atunci este logic să împărțim vizualizarea unui controler de vizualizare în module separate , fiecare implementat ca o vizualizare cu propriul fișier NIB (sau cu mai multe module grupate în același fișier). Avantajul clar al acestei abordări este că fiecare componentă este mai ușor de dezvoltat, mai ușor de testat și mai ușor de depanat.

NIB-urile împărtășesc problemele de conflict de îmbinare pe care le-am văzut cu Storyboard-urile, dar într-o măsură mai mică, deoarece fișierele NIB funcționează la o scară mai mică.

Când să folosiți NIB-urile pentru designul UI iOS

Un subset al tuturor cazurilor de utilizare ar fi:

• Vederi modale
• Vizualizări simple de conectare și înregistrare
• Setări
• Ferestre pop-up
• Șabloane de vizualizare reutilizabile
• Șabloane de celule de tabel reutilizabile

Între timp…

Când să nu folosiți NIB-uri

Ar trebui să evitați utilizarea NIB-urilor pentru:

• Vizualizări cu conținut dinamic, în care aspectul se modifică semnificativ în funcție de conținut.
• Vizualizări care, prin natura lor, nu sunt ușor de proiectat în Interface Builder.
• Vizualizați controlere cu tranziții complicate care ar putea fi simplificate cu Storyboarding.

Pro și contra generale

În general, să trecem prin avantajele și dezavantajele utilizării NIB-urilor.

Pro: Reutilizabilitate

NIB-urile sunt utile atunci când același aspect este partajat între mai multe clase.

Ca un caz de utilizare simplu, un șablon de vizualizare care conține un nume de utilizator și un câmp de text pentru parolă ar putea fi implementat cu vizualizările ipotetice TTLoginView și TTSignupView , ambele ar putea proveni din același NIB. TTLoginView ar trebui să ascundă câmpul pentru parolă și ambele ar trebui să specifice etichetele statice corespunzătoare (cum ar fi „Introduceți numele de utilizator” vs „Introduceți parola”), dar etichetele ar avea aceleași funcționalități de bază și aspecte similare.

Pro & Contra: Performanță

NIB-urile sunt încărcate leneș, așa că nu folosesc memoria până nu trebuie. Deși acest lucru poate fi un avantaj, procesul de încărcare leneș are o latență, ceea ce îl face și un dezavantaj.

Cod personalizat iOS (interfețe de utilizare programatice)

Orice design de interfață iOS care poate fi realizat cu Storyboard-uri și NIB-uri poate fi implementat și cu cod brut (a fost o perioadă, desigur, când dezvoltatorii nu aveau luxul unui set atât de bogat de instrumente).

Poate mai important, ceea ce nu se poate face cu NIB-uri și Storyboard-uri poate fi întotdeauna implementat cu cod - cu condiția, desigur, că este fezabil din punct de vedere tehnic. Un alt mod de a privi acest lucru este că NIB-urile și Storyboard-urile sunt implementate cu cod, astfel încât funcționalitatea lor va fi în mod natural un subset. Să sărim direct în argumentele pro și contra.

Pro: Sub capotă

Cel mai mare avantaj al creării unei interfețe de utilizare iOS în mod programatic: dacă știți cum să codificați o interfață de utilizator, atunci știți ce se întâmplă sub capotă , în timp ce același lucru nu este neapărat valabil pentru NIB-uri și Storyboard-uri.

Pentru a face o comparație: un calculator este un instrument util. Dar nu este un lucru rău să știi cum să faci calcule manual.

Acest lucru nu se limitează la iOS, ci la orice instrument RAD vizual (de exemplu, Visual Studio și Delphi, pentru a numi doar câteva). Mediile Visual HTML RAD reprezintă un caz limită tipic: sunt folosite pentru a genera cod (adesea prost scris), susținând că nu este nevoie de cunoștințe HTML și că totul poate fi făcut vizual. Dar niciun dezvoltator web nu ar implementa o pagină web fără să-și murdărească mâinile: ei știu că manipularea manuală a HTML și CSS brut va duce la un cod mai modular și mai eficient.

Deci, stăpânirea codificării interfețelor de utilizator iOS vă oferă mai mult control și o mai mare conștientizare a modului în care aceste piese se potrivesc împreună, ceea ce vă ridică limita superioară ca dezvoltator.

Pro: Când codul este singura opțiune

Există, de asemenea, cazuri în care codul personalizat iOS este singura opțiune pentru designul UI. Aspectele dinamice, în care elementele de vizualizare sunt mutate și fluxul sau aspectul se ajustează semnificativ în funcție de conținut, sunt exemple tipice.

Pro: Îmbinare conflicte

În timp ce NIB-urile și Storyboard-urile au suferit în mod semnificativ din cauza conflictelor de îmbinare, codul nu are aceeași greșeală. Tot codul are semnificație semantică, așa că rezolvarea conflictelor nu este mai dificilă decât de obicei.

Contra: prototipare

Este dificil să-ți dai seama cum va arăta un aspect până nu îl vezi în acțiune. În plus, nu puteți poziționa vizual vizualizările și controalele, așa că traducerea specificațiilor de aspect într-o vizualizare tangibilă poate dura mult mai mult, în comparație cu NIB-urile și Storyboard-urile care vă oferă o previzualizare imediată a modului în care vor fi randate lucrurile.

Contra: Refactorizarea

Refactorizarea codului care a fost scris cu mult timp în urmă sau de altcineva devine, de asemenea, mult mai complicată: atunci când elementele sunt poziționate și animate cu metode personalizate și numere magice, sesiunile de depanare pot deveni dificile.

Pro: Performanță

În ceea ce privește performanța, Storyboard-urile și NIB-urile sunt supuse supraîncărcării și analizei; și în cele din urmă, sunt traduse indirect în cod. Inutil să spun că acest lucru nu se întâmplă cu interfețele de utilizator create de cod.

Pro: Reutilizabilitate

Orice vizualizare implementată programatic poate fi proiectată într-un mod reutilizabil. Să vedem câteva cazuri de utilizare:

• Două sau mai multe puncte de vedere au un comportament comun, dar sunt ușor diferite. O clasă de bază și două subclase rezolvă problema elegant.
• Un proiect trebuie să fie bifurcat, cu scopul de a crea o singură bază de cod, dar generând două (sau mai multe) aplicații diferite, fiecare cu personalizări specifice.

Același proces de proiectare a interfeței de utilizare ar fi mult mai complicat cu NIB-uri și Storyboard-uri. Fișierele șablon nu permit moștenirea, iar soluțiile posibile sunt limitate la următoarele:

• Duplicați fișierele NIB și Storyboard. După aceea, ei au vieți separate și nicio relație cu fișierul original.
• Ignorați aspectul și comportamentul cu cod, care poate funcționa în cazuri simple, dar poate duce la complicații semnificative în altele. De asemenea, suprascrierile grele cu cod pot face designul vizual inutil și să evolueze într-o sursă constantă de dureri de cap, de exemplu, atunci când un anumit control se afișează într-un singur sens în Interface Builder, dar arată complet diferit atunci când aplicația rulează.

Când să utilizați codul

Este adesea o recomandare bună să folosiți codul personalizat pentru proiectarea interfeței cu utilizatorul iOS atunci când aveți:

• Aspecte dinamice.
• Vizualizări cu efecte, cum ar fi colțuri rotunjite, umbre etc.
• Orice caz în care utilizarea NIB-urilor și a Storyboard-urilor este complicată sau imposibilă.

Când să nu folosiți codul

În general, interfețele de utilizator realizate în cod pot fi întotdeauna utilizate. Rareori sunt o idee proastă, așa că aș pune o Aici.

Deși NIB-urile și Storyboard-urile aduc câteva avantaje la masă, cred că nu există niciun dezavantaj rezonabil pe care l-aș pune într-o listă pentru a descuraja utilizarea codului (cu excepția, poate, a lenei).

Un singur proiect, mai multe instrumente

Storyboard-urile, NIB-urile și codul sunt trei instrumente diferite pentru construirea interfeței cu utilizatorul iOS. Suntem norocoși să le avem. Fanaticii interfețelor de utilizare programatice probabil nu vor lua în considerare celelalte două opțiuni: codul vă permite să faceți tot ce este posibil din punct de vedere tehnic, în timp ce alternativele au limitările lor. Pentru restul dezvoltatorilor de acolo, cuțitul Xcode oferă trei instrumente care pot fi folosite simultan, în același proiect, în mod eficient.

Cum, întrebi? Oricum vrei. Iată câteva abordări posibile:

• Grupați toate ecranele asociate în grupuri separate și implementați fiecare grup cu propriul său Storyboard distinct.
• Proiectați celule de tabel nereutilizabile la locul lor cu un Storyboard, în interiorul controlerului de vizualizare a tabelului.
• Proiectați celule de tabel reutilizabile în NIB-uri pentru a încuraja reutilizarea și a evita repetarea, dar încărcați aceste NIB-uri prin cod personalizat.
• Proiectați vizualizări personalizate, controale și obiecte intermediare folosind NIB-uri.
• Utilizați codul pentru vizualizări extrem de dinamice și, în general, pentru vizualizări care nu sunt ușor de implementat prin Storyboard-uri și NIB-uri, în timp ce găzduiesc tranzițiile de vizualizare într-un Storyboard.

Pentru a încheia, să ne uităm la un ultim exemplu care leagă totul împreună.

Un caz de utilizare simplu

Să presupunem că vrem să dezvoltăm o aplicație de mesagerie de bază cu mai multe vederi diferite:

• O listă de prieteni urmăriți (cu un șablon de celule reutilizabile pentru a menține interfața de utilizare consecventă în listele viitoare).
• O vizualizare a detaliilor profilului, compusă în secțiuni separate (inclusiv informații despre profil, statistici și o bară de instrumente).
• O listă de mesaje trimise și primite de la un prieten.
• Un nou formular de mesaj.
• O vizualizare nor de etichete care afișează diferitele etichete utilizate în mesajele utilizatorului, fiecare etichetă fiind proporțională ca dimensiune cu numărul de ori când a fost utilizată.

În plus, dorim ca vizualizările să curgă după cum urmează:

• Făcând clic pe un element din lista de prieteni urmăriți, se afișează detaliile profilului prietenului respectiv.
• Detaliile profilului arată numele profilului, adresa, statisticile, o listă scurtă cu cele mai recente mesaje și o bară de instrumente.

Pentru a implementa această aplicație iOS, toate cele trei instrumente UI ne vor fi utile, deoarece putem folosi:

• Un Storyboard cu patru controlere de vizualizare (lista, detalii, lista de mesaje și formularul de mesaj nou).
• Un fișier NIB separat pentru șablonul de celule reutilizabile pentru lista de profiluri.
• Trei fișiere NIB separate pentru vizualizarea detaliilor profilului, câte unul pentru fiecare dintre secțiunile separate care o compun (detalii profil, statistici, ultimele trei mesaje), pentru a permite o mai bună întreținere. Aceste NIB-uri vor fi instanțiate ca vizualizări și apoi adăugate la controlerul de vizualizare.
• Cod personalizat pentru vizualizarea norului de etichete. Această vizualizare este un exemplu tipic de una care nu poate fi proiectată în Interface Builder, nici prin StoryBoards, nici prin NIB-uri. În schimb, este implementat complet prin cod. Pentru a menține fluxul vizual al Storyboard-ului, alegem să adăugăm un controler de vizualizare gol la Storyboard, să implementăm vizualizarea norului de etichete ca vizualizare de sine stătătoare și să adăugăm programatic vizualizarea la controlerul de vizualizare. În mod clar, vizualizarea ar putea fi implementată și în interiorul controlerului de vizualizare, mai degrabă decât ca o vizualizare independentă, dar le menținem separate pentru o reutilizare mai bună.

O machetă de bază ar putea arăta astfel:

Cu aceasta, am subliniat construcția de bază a unei aplicații iOS rezonabil de sofisticate ale cărei vederi de bază leagă cele trei abordări principale ale noastre de proiectare a UI. Amintiți-vă: nu trebuie luată o decizie binară, deoarece fiecare instrument are punctele sale forte și punctele sale slabe.

Încheierea

După cum este examinat în acest tutorial, Storyboard-urile adaugă o simplificare vizibilă designului și fluxului vizual iOS UI. Ele elimină, de asemenea, codul standard; dar toate acestea au un preț, plătit în flexibilitate. Între timp, NIB-urile oferă mai multă flexibilitate prin concentrarea pe o singură vizualizare, dar fără flux vizual. Cea mai flexibilă soluție, desigur, este codul, care tinde să fie destul de neprietenos și în mod inerent non-vizual.

Dacă acest articol v-a intrigat, vă recomand cu căldură să urmăriți marea dezbatere de la Ray Wenderlich, 55 de minute bine petrecute într-o discuție despre NIB-uri, Storyboard-uri și UIS realizate în cod.

În încheiere, vreau să subliniez un lucru: evitați cu orice preț să utilizați instrumentul necorespunzător de proiectare a interfeței de utilizare iOS . Dacă o vizualizare nu poate fi proiectată cu un Storyboard sau dacă poate fi implementată cu NIB-uri sau cod într-un mod mai simplu, nu utilizați un Storyboard. În mod similar, dacă o vizualizare nu poate fi proiectată folosind NIB-uri, nu utilizați NIB-uri. Aceste reguli, deși simple, vor merge foarte mult în educația ta ca dezvoltator.