iOS lay-outs: interface builder of zelf programmeren?

Elke mobile app developer heeft een eigen geliefkoosde manier van werken die hij altijd zal verdedigen, of het nu over programmerstijl, debugging of versioning systemen gaat. iOS developers zijn daar niet anders in. Eén van de eeuwige discussiepunten is het implementeren van layouts. In het geval van iOS wordt dit grotendeels door de developer zelf gedaan, in tegenstelling tot webdesign waar er meestal een frontend-developer aan te pas komt.

De grote vraag is: Xcode’s interface builder gebruiken of de layout zelf programmeren?

Bij Duo gaat onze voorkeur naar interface builder (IB), maar laat ons beginnen met de voor- en nadelen op een rijtje te zetten:

Het sterkste argument om je layout zelf te programmeren is dat je in interface builder toch niet alles kan doen. Een heel terecht argument, want hoewel ik fervent voorstander ben van interface builder, moet ik toch regelmatig in de code duiken voor aanpassingen die ik met interface builder simpelweg niet kan doen. Ook om je layout dynamisch aan te maken en/of in te vullen, moet je gaan programmeren.

Hierdoor geraakt de definitie en de code van je layout verspreid over interface builder, wat verwarrend kan zijn voor een mobile developer die nieuw op het project komt. Voor jezelf kan het ook handig zijn als je al een tijd niet meer aan het project gewerkt hebt (en schaamteloos commentaar bent vergeten schrijven). Doordat de definitie van je layout verspreid is, kan debugging soms voor grote problemen zorgen.

Er zijn nog enkele serieuze argumenten tégen interface builder. Waarom kiezen wij bij Duo er toch nog voor om deze tool te gebruiken? Heel simpel, de grootste reden is de gigantische hoeveelheden boilerplate code die eraan te pas komt wanneer je de layouts zelf programmeert.

Interface builder doet heel erg veel voor je, het definieert elk element, legt er een link mee in je code, positioneert het element, configureert de default basis-opties van het element, etc… Als je een element in code aanmaakt moet je dit allemaal zelf doen en wordt je code (onnodig) “bloated”. De meeste mensen plaatsen deze code in hun UIViewController, waar zoiets eigenlijk helemaal niet hoort en dus heel erg onoverzichtelijk kan worden.

Een ander nadeel is dat je gemakkelijk het overzicht kan verliezen door oa. de grote hoeveelheid code. Bij interface builder krijg je meteen een visueel én hiërarchisch overzicht van hoe de layout in elkaar zit. Voor programmeurs op een nieuw project is dit meer dan wenselijk.

Conclusie

Uiteindelijk is er geen zwart-wit oplossing en spelen persoonlijke voorkeur en opleiding hierin ook een belangrijke rol. De gulden middenweg voor ons bij Duo is een combinatie van zowel code als interface builder, maar vereist wel wat ervaring, geduld en goeie afspraken tussen de verschillende teamleden.
Ben ik een belangrijk voor- of nadeel vergeten, of houd je er een ander standpunt op na? Ik hoor het graag in de comments!