Transcriptie: Jeroen Leenarts over iOS development

Welkom bij aflevering 12 van CodeKlets, een aflevering dit keer met mij en Bernard. Hallo. Hallo. We hebben vandaag een gast en ik ben blij dat jij erbij bent Bernard, want dit is een onderwerp waar ik gewoon echt geen ervaring meer heb. Misschien heb ik één keer een idee geopend. Ik ga even niet zeggen welke idee, want dan verklap ik het meteen. En ja, dat is een keer iets gemaakt, maar daar niet noemenswaardig. Onze gast van vandaag is Jeroen Leenaerts. En Jeroen is sinds 2002 werkzaam als software ontwikkelaar. Sinds iOS 3, dat is trouwens echt lang geleden, is hij gespecialiseerd in iOS ontwikkeling. Over de loop van jaren heeft hij met verschillende technologieën en stacks gewerkt. Waaronder Java. Ja, daar moeten we misschien nog even over hebben. Eclipse. Oké, Django. IOS microservice architectuur. En nog meer. Ja, dat nog meer is altijd wel... Dan moeten we nog naar vragen. Ik ben ook Microsoft Certified Application Developer geweest. Echt? Wauw. Wel in .net 1.1 hoor. Oh, dat vind ik ook interessant. Goed. Op dit moment is Jeroen lead iOS developer in de context van drie development teams. Tevens is actief als security champion in iOS. Verder is Jeroen ook community lead van Cocoa Heads Nederland, NL. En organiseert al zeven jaar maandelijkse meetups voor iOS en Mac ontwikkelaars. Verder, teraan alsof dat nog niet genoeg was, werkt hij ook onder zijn eigen naam AppForceOne. En heeft hij deze week zijn eigen podcast gelanceerd. Nou, deze week is natuurlijk een beetje lastig. Als wij dit gaan publiceren, dan zijn we denk ik anderhalve week verder. Ja, 20 oktober. Dan moet het zo ook even over hebben. En de podcast heet AppForceOne, News and Information for iOS App Developers. Dus een Engelstalige podcast neem ik aan. Ja, klopt. Oké. Ja, ja, ja. Cool. Kunnen we het ook nog over hebben. Nou, welkom Jeroen. Ja, hoi. Woehoe. En daar heb ik trouwens nog een heel mooie mooie scene. Heb ik die heel lang gezocht en heb ik hem niet gebruikt. Die kun je ook maar één keer. Je kunt hem niet multiple triggeren. Jammer. Nou, gaan we weer knippen. Welkom, welkom, welkom. Ja, dit is een indrukwekkende bio. Ik vind het wel grappig, want je bent sinds 2002. Dus als ontwikkelaar begonnen, was je toen met .net begonnen of niet? Nou ja, dat is. Want .net 1.1 is 2003 ongeveer. Ja, 2003. Ja, ja, ik ben mijn opleiding heb ik van 1998 tot 2002 gedaan. HBO in Zwolle. En dat was een beetje een aparte opleiding, want na de eerste twee jaar toen was er gewoon geen curriculum meer. Dus toen zijn we met zes man voor de examencommissie gegaan en van eigenlijk gewoon de vraag gesteld. Oké, en nu? Nou, toen hebben we voor de laatste twee jaar hebben we een docent toegewezen gekregen die een fulltime voor ons zesde bezig was. En toen hebben we de laatste twee jaar van onze opleiding eigenlijk zelf ingevuld. Dus dat was echt flink feesten. Nou, en uiteindelijk heeft hij het papiertje opgeleverd dat ook nog geldig is. Als we vragen van wat is je diploma, dan zeg ik HBO IT. En dan geloven ze me, dus het zal wel goed zijn. Dus ja, in mijn opleiding veel met Java gedaan. Want ja, in die jaren was het echt alles Java, Java, Java, Java, Java. Zoals het nu allemaal Python is, geloof ik heel veel op hoge scholen en universiteiten. Oh, dat weet ik niet eens trouwens, ja. En ja, dus ik ben dus eigenlijk als een soort Java developer, ben ik het werkveld ingerold bij InfoSport. Dat is een consultiebedrijf ergens in en daal. Ja, dat ken ik. Negen jaar gewerkt. Maar toen ik daar begon, was het allemaal een beetje zo van ja, we zijn een dotnet bedrijf. En ja, je krijgt nu eerst een half jaar trainingen voor Microsoft.net. Nou, en zo ben ik dus inderdaad gecertificeerd geraakt voor Microsoft Certified Application Developer. En ja, ik lag me nog steeds kapot, want ik ben dat ooit geweest, maar ik heb er eigenlijk nooit wat mee gedaan. Ik heb mijn afstudeerproduct, wat ik bij mijn eerste werkgever had gebouwd, we hadden hem in Java geschreven en toen hadden we hem gewoon voor de grap. Om te leren hadden we hem nog een keertje in dotnet herschreven. En dat was het allermooiste, dat ding dat heette Mealyways. En het was een applicatie op het internet waarmee je broodjes kon bestellen voor de lunch. Dus heel nuttig. Ja, zeker. Ja, en het was echt een multi-tenant applicatie, want je kon gewoon meerdere leveranciers konden een menu erin in krijgen. En aan het einde van de maand dan rolde daar een printje uit. Dat ging naar de loonadministratie toe. En dan kon je zien hoe erg de schade was op je loonstrook. En toen ik per het bedrijf wegging, dat was negen jaar later, toen draaide dat ding nog steeds. Oh, echt? Over de loop der jaren wilde iemand anders hier en daar langzamer ge-upgrade. Ik weet niet of het nu nog draait, maar zo ben ik dus inderdaad met dotnet in aanraging gekomen, heel even. En toen heb ik eigenlijk eerst tot heel veel Java-dingen gedaan, maar rond de Eclipse RSHP, front-end, back-end, nou ja, echt ouderwet Java Enterprise Beans geschreven. Dat je echt gewoon iets van vier verhaals nodig hebt om één objectje te definiëren op IBM WebSphere. Ook met Oracle. Ik weet niet meer eens hoe het dat ding heet, joh. Dat was nog voor die goudvis applicatieservice. Ik weet niet eens hoe die meer heet. Ik weet het ook niet. Ik weet dat er... Sun Microsystems bestond toen nog. Ja, maar dat heeft nog genild. Dat is op zich nog best wel lang doorgegaan. Het is niet per se heel lang geleden dat Oracle het overgenomen heeft. Maar dat is wel in ieder geval... Nee, Oracle had toch... Ja, een applicatieservice die draaide op die database ofzo. Dat weet ik niet hoe dat... Ja, ik bedoelde dat de hele play van Oracle was altijd dat ze gewoon die database door je strotten en doorduwen. En als je dan die database had, dan was je op een gegeven moment afhankelijk van ze. En dan gingen ze de licenties opschroeven. Dat is wat Oracle altijd gedaan heeft. Ja. Heel verkenbaar. Kijk, Java, voorbij Java.net, bedoel ik ben... Java.net is een beetje Ajax Feyenoord. Ja. Ja, dat is gewoon... Wat is je voorkeur? Nou, dat zal wel. Maar Oracle, dat is echt... Ik weet het niet. Ik vind het niet zo'n heel relaxed bedrijf, omdat dat heel erg salesgedreven is. Ja, ze wilden laatst wel bijna TikTok kopen. Ja, dat is volgens mij nog steeds aan de hoogte. Maar de manier ook van hoe die licentie... Ja, precies wat jij zegt, hoe het heel erg opgedrukt wordt om maar meer licenties te verkopen. Ja, dat zal bij Microsoft ook gebeuren met SQL Server en andere bedrijven ook. Maar bij Oracle was het heel erg agressief. Maar goed, dat... In ieder geval heel veel dingen met Java gedaan. Echt van alles en nog wat. Ook wel eens een keer naar een conferentie geweest in de Amerika ervoor. En gewoon echt leuke dingen gedaan. Ik heb bijvoorbeeld bij de NS aan een planningsproduct gewerkt met Eclipse RCP. Dus dan heb je dus de Eclipse IDE, die ken je wel. Ja, ja. Nou, een Eclipse RCP is dan dat ding, maar dan uitgekleed. En dan maak je daarin eigenlijk je eigen applicatie, zeg maar. Dus dan is dat een soort van runtime plug-in architectuur, waarin je dan leuke dingen... Beetje zoals nu Electron is, zeg maar. Nou vloek ik, maar dat is wel een beetje stil. Ja, misschien wel. Ja, ik ken Electron goed genoeg. Ja, want het principe... Ja, goed. Ik heb zelf niet met Eclipse gewerkt, maar ik heb toen... Nee, de Java-developer was waar ik mee werkte, zeg maar. Of die in ons team zaten. Die hadden Eclipse. En er was één jongen, die zei dat toen ook. Die heeft me toen laten zien van oké, je kunt Eclipse ook gewoon als platform en gebruiken om naar je eigen applicatie te draaien. En dat was op zich wel, vond ik wel, een interessante propositie, zeg maar. Maar dat is nu ook wel... Ja, dat is niet per se commercieel een enorm succes of zo. Niet dat ik weet. Maar Electron is op zich heel populair. Ik weet niet, iedereen klaagt natuurlijk dat het veel gebruik is. Maar dat is wel zo. Het enge van Electron vind ik dat je eigenlijk gewoon een complete webomgeving op je machine draait. En dat werkt heel mooi. Je bent er heel snel mee waarschijnlijk en zo. Maar qua security, die hele browser sandbox die eromheen zit in je webbrowser, die is gewoon weg. Dus als er gewoon een vulnerability in dat Electron zit, dan ben je binnen. Dat vind ik een beetje het nadeel van Electron. Zeker als het slack is bijvoorbeeld. Ja, ik weet niet wat slack verder nog doet. Al die gekke gifjes en zo die je binnen krijgt. Dat weet ik van wat mensen allemaal posten. Als je een inline documentje viewt of zo. Bam, roet, doei. Ja, ik weet het niet. Ik weet niet wat slack daar aan doet. Ik vermoed, want Visual Studio Code is natuurlijk ook... Ja, maar dat is anders. Ik bedoel Visual Studio, dan ben je zelf meer in controle. Je installeert wat plugins en zo. Maar het is niet dat een random weirdo die ook al bij jou op de Slack channel zit, gewoon bestandjes naar je kan sturen. Dat is wel een verschilletje. Ja, klopt. Dat valt me dan tot nu toe op. Dat er nog niet een, ja, misschien is er wel. En dan weet ik het nu nog niet. Maar op zich zijn er nog niet heel veel breaches geweest, volgens mij, in Slack zelf. Slack zelf, nee, dat klopt. Maar goed, we zijn er weer afgetwaald, geloof ik. Ja, dat gebeurt vaker. Ja, laten we kijken hoe jij bent begonnen met iOS. Ja, ik zat dus bij dat infosupport en dat was hartstikke leuk en zo. En toen had je op een gegeven moment de iPhone 2, of ik weet niet hoe die heet, maar in ieder geval die zilverkleurige achterkant met die zwarte rand aan de onderkant was, geloof ik. Ja. Nou, dan had ik echt zoiets van... Toen was in die tijd van ja, we hebben helemaal geen appjes nodig. JavaScript, dat is prima genoeg en alles in de browser. En toen je met iOS 3 bedacht dat dat toch niet zo'n goed idee was, of tenminste Steve Jobs dacht dat het niet zo'n goed idee was. Nou, wacht, dat is het minste. De overlevering is dat Steve Jobs die vond dat browser idee goed en de rest volgens mij van de bedrijven die zei nou, misschien moet je dat maar even iets omheen doen. Nou, en toen kwam dus dat iOS, dat werd toen zeg maar, dat je echt daarop kon ontwikkelen. Nou, dat leek mij wel interessant, dus daar ben ik er gewoon in mijn eigen tijd een beetje naar gaan kijken. Toen op een gegeven moment ook gewoon zo gek geweest dat ik voor mijn eigen geld een MacBook, volgens mij was het een MacBook Pro, echt zo'n G4 was dat gekocht. Ja, want je hebt toch een Mac nodig om iets met die spullen te kunnen doen. En nou, dat was leuk, een beetje spelen. Dat was nog net voor dat Xcode uit was gekomen. En had je nog echt de interface beelden, had je nog echt apart. Nou, echt joh, dat was echt verschrikkelijk. En toen was het eigenlijk, zat ik eigenlijk een beetje mijn manager binnen dat bedrijf, zat ik ook een beetje te pushen van ja, kunnen we niet even een klusje vinden voor een mobile ofzo, iets met iOS ofzo, het lijkt me wel leuk. Kunnen we dat niet doen? En constant, constant volhouden gewoon. En uiteindelijk heb ik daar dan een soort of proof of concept voor Kaspank mogen doen in Amsterdam. En dat was met grafiekjes en zo. En dat moest dan een iPad app worden. En dat mocht ik twee weken aan besteden. Dus echt twee weken er echt als een debuul op de keer gegaan, zeg maar. Ik had nog geen kinderen, dus dat kon gewoon oneindig tijd in een week, zeg maar. En dat was leuk. Maar het was geen project geworden. Nou, ik balen natuurlijk, want wat nu dan? En toen ben ik uiteindelijk ben ik een beetje gaan solliciteren, zeg maar. En toen kwam Xebia, die kwam in beeld. Daar ken ik Kishen ook van. En toen heb ik eigenlijk gewoon gezegd, ja, ik wil best wel bij jullie werken eigenlijk. Maar dan wil ik wel gewoon iOS doen. Ik heb geen ervaring eigenlijk die noemenswaardig is, maar dat is wat ik wil doen en niet iets anders. Dus kan dat? Nou, dan hebben ze even wat moeten overleggen en zo. En toen hebben ze, uiteindelijk hebben ze bij een grote klant van hun, hebben ze dat eigenlijk voor elkaar gekregen. Dus ik had getekend en toen mijn eerste dag, ik zat gelijk aan de Haarlemmerweg in Amsterdam, in hoofdgebouw 2 bij de ING. Nou, dit is Jeroen. Hij is heel goed in iOS. En vervolgens liep mijn nieuwe manager heel hard weg. Oké. Dat scheelde. Ik had daar wel een collega bij me, Andrew Snair. Dat was een Australier en echt een hele coole, goede vent is dat. En die heeft me eigenlijk gewoon, na 2, 3 weken heeft hij me eigenlijk onder zijn vleugel genomen. Dat was een directe collega van Xebia, dus dat kon een beetje harsje, harsje onder de hoed, zeg maar. En na 2, 3 weken had hij zoiets van, dit loopt wel los. Die Jeroen, die kunnen we gewoon zijn ding laten doen, zeg maar. Nou, en toen ben ik eigenlijk gewoon een beetje onder job met AOS development begonnen. Dat was in de tijd dat die ING-apps, je had eerst van die vier grote knoppen, zeg maar, en dat is toen na zo'n hamburgermenu gegaan. Ja, cool. Dat hamburgermenu heb ik gemaakt. De pinpad die er nu net sinds, ik denk dat het er nu anderhalf jaar echt uit is of zo, met die stelletjes die een beetje pulseren, heb ik gemaakt. Maar de spaarbalk die die animatie er in schuift, die je nog steeds ziet, die heb ik gemaakt. Dat is heel grappig, want zoveel jaar later zitten er nog steeds dingetjes. Ja, natuurlijk, de code zal al lang veranderd zijn, maar je herkent wel dat dan een bepaalde touch van je er nog aan zit, zeg maar. Want ik zat er altijd echt ontzettend lang door te zeuren van, ja, met animaties en zo. Ja, dat moet allemaal, nou ja, echt allemaal bizarre dingen. Want als je bijvoorbeeld zo'n sterretje, wat dan in zo'n pinschermpje, wat dan in beeld komt, heel veel mensen denken, ja, plop, één fate en één scaling en het is klaar. Maar dat ding komt op het scherm met vijf verschillende animaties, die allemaal op verschillen, en dan de drie ervan, zit op een andere tijdlijn dan die andere twee. Oké. En dat allemaal maar gewoon om, ja, goed, ten eerste omdat het leuk is en ten tweede omdat het kan. En ten derde, verkopen het ook goed, ja, want dan is het dan voelen mensen zich geconnected met, en daar hebben wij goed. Op een gegeven moment leer je het heel goed verkopen, zeg maar, en je gewoon leuke dingen kan bouwen die je zelf wil. Nou heb ik dus echt vier jaar en drie maanden bij de ING gezeten, dus gewoon Dedicate het iOS Development gedaan, daar dus eigenlijk gewoon begonnen. Toen ook, daar komen we straks nog wel op denk ik, op een of andere manier Cocahats ingerold, zeg maar. En aan het eind van die rit heb ik nog een soort van conversieproject gedaan met Jeroen Willemsen en Nan de Baars, die waren toen ook van Xebia. En toen hebben we eigenlijk de onderliggende netwerklaag van de app, hebben we toen als een soort van component eruit getrokken, of eigenlijk opnieuw gebouwd en dan gebaseerd op wat ze daar hadden, zodat ze dat op andere mobiele producten konden gaan hergebruiken. Dus dan heb je het over SCP-6a, en dat is dan een passwordafleiding, en allemaal encryptie en weet ik veel wat allemaal. En dat je dan dus dat allemaal maar een beetje in je vingers moet krijgen en dat je denkt van ja, wacht even, ze zeiden toch altijd iets met encryptie, dat moet je toch nooit zelf doen. Nou, maakt niet uit, we gaan gewoon bouwen. Er komt een security review en dat komt wel goed. En inderdaad gewoon met de drieën daar gewoon volgens mij negen maanden echt aan zitten klussen, zeg maar. En toen was het eigenlijk voor mij, er kwam dus een situatie dat ik, toen ik bij Xebia begon ook mijn huidige vrouw leren kennen, nou goed, dan op een gegeven moment komt het onderwerp kinderen in beeld en toen toch vanwege reistijd een move gemaakt weer. Dus ben ik weg gegaan bij Xebia, ben ik bij een kleine agency in Apeldoorn terecht gekomen. Dat was negen maanden, ja, dan werd ik net te gek van mijn baas. Dus toen had ik zoiets van dit is hem niet. Toen ben ik weer terug gegaan naar een bedrijf in Amsterdam. Dat was een iPad app die voor fashion retail inkoopbegeleiding deed. Dus dan kon je dat als mode winkel of mode keteneigenaar, ga je eigenlijk gewoon ook kleding kopen. En alleen ja, de schaal waarop je dat doet is natuurlijk, als ik naar de kledingwinkel ga, dan koop ik eens een shirtje van broek of zo, en dan ben ik klaar. Maar die luiden kopen gewoon compleet dingen wat ze noemen maatbogen. En dat is eigenlijk gewoon de kleine maat en een beetje de grote maat en een beetje. En hoe meer het naar het gemiddelde komt, hoe meer ze ervan willen hebben. Oh ja, ik snap het. Het zijn dus echt luid. Die gaan gewoon even shoppen en die doen even een rondje bij ja, eigenlijk gewoon fashion bedrijven die dan ook gewoon een soort van warehuizen in Nederland hebben waar je dus je inkoop kan doen. Dus daar hangen er artikelen gewoon om daadwerkelijk te kijken en te voelen. Dat is voor die mensen heel belangrijk. Want ja, het is toch een heel erg persoonlijk en intiem productkleding. Maar dan lopen ze zo'n gebouw binnen en dan gaan ze shoppen, shoppen, shoppen, shoppen en aan het eind van de dag hebben ze vier tonnen uitgegeven. Alleen ze hebben echt geen flauw idee hoeveel ze eigenlijk ingekocht hebben. En daar begeleidt het product dan dus eigenlijk bij. Dat je ook kan zien van nou, heb ik een beetje de goede mate? Heb ik niet te veel van één kleur? Want het was ook allemaal visueel met foto's en weet ik voor wat allemaal. Nou, dat was hartstikke leuk, want daar zat dus ook een heel groot cloud component bij. Dus Amazon Web Services met Django Rest back-end microservices. Maar in welk jaar was dit dan? Dat was bij... Ja, ik moet even denken wat het was. We zitten nu al in... Nu moet ik ook mijn eigen aantekeningen pakken hoor. Ja, op dat je 2020... Nee, dat was in 2017. Daar ben ik in 2017 begonnen. Ik heb in 2016 negen maanden bij de App Agency gezeten. Toen in 2017 ben ik bij Neon Fashion Retail gaan werken. Daar heb ik een jaar en vier maanden gewerkt. Echt super naar mijn zin gehad. Dat was echt zo van... Ja, ik heb ooit wel eens iets met back-end gedaan, Java. En Erwin was dan de lead developer daar. Hij zei, oh, maar dan kun je ook wel Python en Django Rest. En hier heb je een PyCharm licentie. Succes. Succes, ja. Ga maar krassen. Gelukkig was ik dan redelijk thuis in Unix en Linux en al die command line shizzles. Dat was een van de redenen waar ik ook een interesse in Mac had. Omdat daar toch een Unix gebaseerd subsysteem op zat. Het is geen echte Linux, maar toch. Je hebt een volwaardige command shell en zo. Ja, dat klopt. Wat is het? Default bash shell en... Precies. Ja, nu is het C-shell. Ja, dat klopt. Ja, ik had hem zelf wel als default. Nu op Mac is dat de default als je kala installeert. Ja, klopt. Daar had ik hem niet door. Dat was wel even wennen hoor. Ja, voor mij viel het mee. Want ik doe niet per se heel erg rare dingen. Want ik installeer, weet het, O-My-Z-Shell. O-My-God, weet ik veel. Ja, O-My-Z-Shell. Heb je allemaal completions en zo, ook voor Git. Ja, precies. Dus dat heb ik dan allemaal. En dan kun je op command al heel cool doen. Alsof je, hoe heet het ook weer, Pauline bent. En alles van Git af weet. Gewoon tap, tap, tap, tap, tap. En het staat allemaal voor je neus. Dat, ja, ja, ja. Dus dat is echt, ja, dat heb ik niet. Ja, dat. Dus ik ben vooral echt gebruiker. Maar dat is ook echt wel lang geleden op school. Zeggen we toen echt Unix op SunOS. Zeg, SunOS. Klopt dat, SunOS? Ja, Solaris. Ja, Solaris, ja, precies. Nee, SunOS is iets anders volgens mij. Maar goed, Solaris. Ja, toen had ik echt wel wat Shell scripts en zo. En dat had ik me daar wat meer even diep. Maar dat weet ik echt nu helemaal niet meer. Ik ben gewoon echt redelijk gebruikt. Alleen, ik vind Cometa wel fijn geworden. Elke dag, toch even een beetje. Ja, het is toch fijn. Het is vaak op bepaalde dingen. Maar even terug. Ja, ik zat dus in 2017 bij dat fashion bedrijf. Ja. Met Python, Django. En ook heel veel op bepaalde stukken op een gegeven moment van die stack. Omdat het heel erg elastic wat we daar qua load hadden. Hebben we dat op een gegeven moment ook naar lambda functies herschreven. Dus daar kwam er op een gegeven moment gewoon een nieuwe catalogus van een bedrijf binnen. En ja, lambda dat zijn, zeg maar, functions as a service. En dan kwam dat gewoon binnen. En dan, nou ja, dan in plaats van dat er dan een VM met je al stond te pruttelen en er klaar voor was. Die volledig unrespect was voor wat je nodig had. En dan vervolgens als je nou twee uur aan het stampen was. Nou, dan had je gewoon met lambda functies had je gewoon. Nou, dan was je jobs moest je even opknippen, starten. En dan ging dat parallel met 150 instances en dat duurde dan een minuutje of zo, weet je wel, in plaats van twee uur. En het was nog eens goedkoper ook. Dus nou, iedereen blij. En nou, betere kwaliteit en je bent sneller. Wat wil je nog meer? En dat soort dingetjes hadden we daar dus. Maar goed, ook daar gewoon echt gewoon Linux server onderhoud moeten doen. Natuurlijk wel virtueel. Maar ja, die krengen, die moesten wel geupdate worden. Dat was allemaal een beetje op de bonnen voor je, was het allemaal ontstaan daar. Dus het was ook niet helemaal infrastructure as code, zeg maar. Dus het was allemaal nog wel een beetje handmatig je instances bijwerken en updaten. En nou, hartstikke leuk. Maar ja, toen kwam de tweede. Kind. En toen was het verdraaid. Ja, het is toch wel fijn om toch wat dichter bij huis te zijn. Ja, dat snap ik. En het grappige was toen dat van mijn huidige werkgever. Ik werk bij Achmea, een grote verzekeraar met callcenters en zo. Dat even terug grijpen naar die opmerking voor iemand. En toen was het eigenlijk, dat was dan die recruitment daar. Maar daar had ik dan contact mee vanwege CocoHats. En nou ja, daar hadden we eens een keertje een meetup mee georganiseerd. Dat was allemaal prima. Maar ze bleef maar achter me aan zitten, bleef maar achter me aan zitten. Dus elke maand of zo, dan kreeg ik wel een belletje of een e-mailtje. Ik werd gewoon gestalkt door haar. Maar uiteindelijk had het effect. Dus ben ik op een gegeven moment zoiets van nou, oké, vooruit dan. Ik kom wel een keer op gesprek. Een week later had ik een contract. Ja, dat snap ik. En daar werk ik nu sinds 2018 alweer. Zo de knut. Dat was al 2,5 jaar. Ik ben in mei 2018 begonnen. Dus dat is een beetje wat ik qua werk gedaan heb. En ja, en eigenlijk bij Achmea weer volledig op iOS gefocust. En ja, ook het backhandwerk een beetje weer laten gaan. Maar ja, goed, dat zijn van dingen die je prutsen eens een keer wat aan. Of je helpt eens een keer iemand op wat kleinere schaal. En dan blijft het toch wel een beetje mee bezig. Ja, precies. Oké, nou, duidelijk. Kan je misschien iets vertellen over hoe dat dan gaat? Zo'n iPhone appje bouwen. Wat gebruik je? Waar begin je? Wat gebruik je niet? De huidige staat van iPhone development voor newbies. Ja, als je echt gewoon met iOS development wil beginnen, dan is het eigenlijk gewoon gaan naar de App Store. En zoek op Xcode en download dat. Als je op download hebt geklikt, dan kun je waarschijnlijk nog eventjes boodschappen gaan doen ofzo. Want dat is echt een hele grote download. Een paar gigabyte. En het gaat om de ene van de reden niet zo heel snel. Als je die ge-download hebt en je start voor de eerste keer op, dan kun je nog een keer boodschappen gaan doen. En als je dat gedaan hebt, dan heb je ze eigenlijk gewoon in IDE beschikbaar. Waar dan ook een virtuele simulator van een iPhone of een iPad of dat soort dingen zit erin. En dan is het best wat je eigenlijk kan doen, is gewoon eens een keertje op de developer documentatie van Apple kijken. Gewoon kijken wat daar een beetje staat. Eerst een beetje bekend raken met de dingen daar staan. Op zich wel een paar basale tutorials, om het zo te zeggen. En dan komt er een punt dat je op een gegeven moment echt serieus moet gaan worden. En dat heb ik gemerkt dat dat voor de meeste mensen die er echt in willen stappen, dat dat dan toch wel het beste gaat met een boek dat heel lang heel erg populair was, was van de Big Nerd Ranch. En dat is echt een soort van guide. Als je daar gewoon aan het begin begint, ze beginnen een beetje eerst met de taal en dan op een gegeven moment een beetje wat de echte concepten zijn binnen iOS, je viewcontrollers en wat je restricties zijn waar je rekeningen moet houden omdat het een mobiel device is. En dan ga je er gewoon doorheen. En dan begin je met de type in de... Ja, eigenlijk wel. Dat zijn we echt van die tutorialachtige stappen waar je dan doorheen gaat. En hopelijk valt dan op een gegeven moment het kwartje. Want het probleem van heel veel developer documentatie en ook bij Apple is dat de voorbeelden die ze erbij als code hebben, zeg maar, dat zijn allemaal heel erg van die afgeschermde, ingekapselde kleine voorbeeldjes. En het probleem daarvan is dat iedereen dan die er niet verder denkt, denkt ja, zo moet je doen. En dat resulteert dus dat echt iedereen alle code maar gewoon in een viewcontroller pleurt. Ja, dat wordt vrij snel, vrij onoverzichtelijk en lastig, zeg maar. Ja, maar nog even een stapje terug. Is het dan, de big nerd range boek was volgens mij Objective-C, als ik het goed heb. Volgens mij zijn ze ook wel geüpdatet nu naar een Swift. Maar wat is Objective-C en wat is Swift en is dat niet hetzelfde, stiekem? Oh nee, zeker niet. Nee, nee, nee. Eigenlijk Objective-C, dat is voor de nieuwe iOS developers, die proberen dat echt gewoon alleen maar aan te raken met een hele lange stok. Het is een soort van Frankenstein creatie tussen C en smalltalk, om het zo te zeggen. Dus ja, wat is het eigenlijk? Het is een soort van syntactic sugar over C heen, die je eigenlijk ook helemaal niet ziet, dat die syntactic sugar er op meen zit. Die syntactic sugar is wel echt bizar met vierkante blokhaken. Ja, veel vierkante blokhaken. Als je een C-achtige taal gewend bent, dan de eerste keer dat je Objective-C code ziet, dan denk je echt van, hoe dan? Wat is dit? Hoe lees ik dit? Het gekke is een beetje als je mensen spreekt die voor geruime tijd Objective-C geprogrammeerd hebben, die vinden overal waar ze binnenkomen, vinden ze de functienamen en de variablenamen tekort. Want Objective-C is een taal die zich ontzettend leent om echt functienamen en klassennamen te verzinnen die echt stukjes proza zijn bijna. En ja, wat is Objective-C? Dat is eigenlijk een dialect over C heen die objectorientatie toevoegt aan een C-taal. En het grappige is ook dat je in Objective-C dus ook echt volledige toegang hebt tot alles wat je in C kan doen. Is heel leuk. Is ook heel gevaarlijk. Want wat kun je met C? Hele mooie crashjes veroorzaken. En dat is dus ook wel echt een van de grootste pluspunten van als je Swift gebruikt. Ik leg zo uit wat dat een beetje is. Dat is dat Swift je veel meer beschermt tegen die typische memory- en stack-gerelateerde fouten die je in C kan maken. Je zet gewoon overal een uithoerteken achter. Nou... Optionals zijn cool. Doe dat niet. Mensen die overal een bang achter zetten hebben echt zoiets van nee, niet doen. Nee, doe dat niet. Nee, dan kan je net zoveel kapotmaken als in Objective-C bijna. Het crasht dan net zo hard in de dag. En wat is Swift? Swift is eigenlijk een nieuwe taal ontwikkeld door Chris Labner. Die zat toen hij dat deed bij Apple. Inmiddels heeft hij alweer bij de Tesla gezeten en ik weet niet waar hij nu zit. Maar die heeft in ieder geval in opdracht van Apple een taal ontwikkeld dat aanvankelijk pitcht. Dus het is een Objective-C++ geloof ik zelfs nog. Maar het is dus echt een C-achtig opgemaakte taal. Dus inderdaad met typische accolades en functiehaakjes zoals je dat eigenlijk een beetje kent vanuit C. En dat soort talen is Java of C-sharp. En het geeft je gewoon veel meer houvast in ieder geval voor wat betreft memory management. Want toen ik begon met iOS development had je echt nog dat je handmatig je geheugen beheer moest doen met retains en releases en zo. En je had ook wel van die autorelease-pools en zo. En die werden nooit op het juiste moment gedraind en zo. Maar wat Swift dus eigenlijk deed, die heeft een iets elegante manier om je reference counting te doen. En daardoor heb je, sowieso als je met Swift programmeert, heb je iets minder kans dat je echt grote memoryproblemen veroorzaakt. Ik bedoel je kan nog steeds dezelfde problemen veroorzaken. Maar goed, wat is het voordeel van Swift ten opzichte van Objective-C? Swift is een taal die voor de gemiddelde ontwikkelaar wat beter leerbaar is. Omdat het gewoon een wat meer eenduidige syntax is. Er zitten minder bizarre implementatiedetails aan. Want dat was toch wel een dingetje met Objective-C. Omdat het een soort van uit de hand gelopen hek op C is, zaten er best wel spannende dingen in af en toe, zeg maar. Ja, ik ben ook wel blij dat ik van die .h-files af ben, merk ik nu. Want ik zit nog op projecten die worden door elkaar gebruikt. Swift en Objective-C. En ik begin er toch al stiekem aan te wennen dat die weg zijn. Of weg raken. Maar als je dan zit te typen in Swift of in Objective-C, wou je ook zo de interface op, gewoon in code? Ja, daar zijn de meningen over verdeeld. Je hebt in, van oudsher, als je Apple-gerelateerde development doet, heb je een concept wat ze de interface builder noemde. Voordat er Xcode was, was de interface builder echt daadwerkelijk een apart programma wat je naast je, volgens mij heette het project editor ofzo, ik weet niet eens meer hoe het ding heet, maar dat was inderdaad soorten met van je code editor. En je had dus echt je code editor en je visuele editor, dat waren gewoon twee dingen die je naast elkaar gebruikt. Twee applicaties. Xcode, dat was het grote ding van Xcode, die integrerde dat met elkaar. En ja, wat je dus qua user interface kan doen, je kan ten eerste natuurlijk al je user interface elementen gewoon in code definiëren, dat je dus inderdaad de dingen aanmaakt en dat je het op z'n plek zet en alle layoutzaken, dat je die ook gewoon goed doet, zodat het ook inderdaad, zodra je het op je scherm ziet, dat het ook op de plek staat waar je het wil hebben. Maar je kan ook interface builder gebruiken en dan kun je dus eigenlijk in een soort van visuele manier kun je componentjes op een scherm slepen en dan kun je dan inderdaad, ja, wat ze dan noemen, die kun je dan wiren met je code, zodat je dus vanuit je code en dat wat je visueel hebt opgemaakt, dat daar dan ook een verbinding tussen is. En ja, wat daar vervolgens weer op nieuw gekomen is, is wat ze nu noemen SwiftUI. En dat is een, ja, dat is iets nu wat nu, sinds iOS 13 kun je dat als iOS developer doen. Dat is een meer declaratieve manier om user interface te definiëren in code. Maar zoals we het opgezet hebben, kan het ook heel goed een soort van preview rendering doen van datgene wat je in code aan het doen bent. En dat maakt eigenlijk dat je, terwijl je typt en het syntactisch weer correct is, dan staat het gelijk in het schermpje ernaast bijgewerkt op je scherm. En dat zijn nu eigenlijk de drie smaken die je hebt. En ja, in ieder geval, bij Achmea zijn we nu echt bezig voor het centraal beheerproduct om, ja, nog steeds om de Objective-C code te lozen. Er zit nog iets van 15 procent van onze code is nog Objective-C. Maar we gaan zeer binnenkort echt volle bakken op SwiftUI duiken. Raak je dan niet oude iOS-feesjes kwijt? Ja. Zo beerd? Ja, we weten de percentage van eindgebruikers die daar last mee krijgen. Ja, dat zijn er niet veel. En Business heeft natuurlijk wel op input van de development teams. Hebben die besloten dat inderdaad het verlies van die gebruikers niet opweegt tegen de pluspunten ten aanzien van verwachte productiviteiten toename. Nee, je kent alle voor's en tegenste wel dat je iets kost je wat, maar het levert ook wat op en het valt nu positief uit. En daar zijn we als developers erg blij mee. Oké. Maar vanaf welke versie zeg maar, welke versie valt af? Volgens mij voor 13. Ja. Oh, oké. Dat is wel redelijk recent. SwiftUI is beschikbaar sinds iOS 13. Ja, oh ja, SwiftUI, sorry. Kijk, en dat we ermee bezig gaan betekent ook niet gelijk dat we het al live hebben. Natuurlijk. We blijven. Nee, maar goed, ik dacht vooral omdat security voor in de financiële sector is wel redelijk belangrijk. Dus je kunt ook zomaar zeggen van ja, heel leuk. Maar we gaan iOS, ik weet niet eens wat, 9 of 10 ofzo. Ja, die wordt niet meer geupdate en dan komen we geen security patches meer op. Maar die gaan we dus gewoon niet meer ondersteunen, omdat het operating system zelf gewoon niet veilig is. Dat weet je, dat je vanuit die insteek. Ja, het is eigenlijk, als je puur door een securitybril kijkt naar het iOS-ecosysteem, dan moet je eigenlijk alles voor iOS 13, moet je al niet meer gebruiken. Moet je gewoon echt niet doen. Kijk, iOS 12.4 is nog, er wordt nog wel gepatcht, zeg maar. Maar ja, er zijn echt gewoon, op iOS 12 zijn al gewoon issues bekend die niet opgelost zijn. Ja, het is gewoon, wat moet je anders? Je kent altijd wel die oude oom of tante die nog een telefoon van vijf jaar oud heeft en roept dat ze het nog prima doet. Ja, dat klopt. Dat is wel weer zo. Maar goed, ja. Ja, aan de andere kant, want mensen klagen er wel van dat het niet, dat je niet meer ge-updated wordt. Maar het feit is wel dat je in het, als je een iPhone koopt, als je nu vandaag naar de winkel gaat, oké, als je nu vandaag op het internet gaat en je koopt een iPhone, dan weet je eigenlijk vrij zeker dat je daar minstens vier, vijf jaar updates op krijgt. Ga je een Android kopen, dan, nou, als je, als je één of twee jaar updates krijgt, dan heb je geluk. Ja, dat is echt een groot verschil. Het is misschien, ja, goed, volgens mij met Google Telephones is het nog. Ja, maar wie koopt er nou een Pixel? Nou ja, de price-prestage-verhouding is volgens mij best goed. Dat wel, ja. Dan heb je dus het voordeel dat die, dat die bijgeweegd. Maar goed, even, dat is even... Dat is een ander probleem, hoor. Ja, precies. Nee, maar goed, ik begrijp, dus dat telt dus wel mee. Dus dat je ook gaat kijken van, oké, hoe veilig is dat op deze situatie? Ja, want het is wel, als je kijkt naar de toestellen die iOS 13 kunnen draaien, ja, de cut-off van de device, dat ligt echt iets van vier jaar in het verleden. Dat zijn de devices die toen uitkwamen, die supporten we dan niet meer. Ja, en als iemand dan niet beslist voor zichzelf om niet naar een nieuwe iOS-versie te updaten, ja, dat is aan de eindgebruiker zelf natuurlijk. Ja. Want iemand wil zijn jailbreak niet kwijtraak ofzo. Ja, nou ja, heel flauw gezegd. Die eindgebruiker wil je ook niet hebben dat die je verzekeringen-app eigenlijk draait. Want ja, hoe lekker zijn mandje is dat device van die gebruiker? Want je bent als... Ja, precies. Je bent als leverancier van die software, dat appje, ja, je wordt er wel op aangekeken als er toch onverhoopt iets misgaat. Ja, klopt. Ondanks dat je er... Het staat in de voorwaarde, je hebt mensen gewaarschuwd. Ja, het kan toch best nog wel eens misgaan. Is het wel zo dat opzet van het product waar ik aan werk, dat je eigenlijk niks kan, ook al heb je full access tot de gegevens van die eindgebruiker op het toestel. Maar dat is meer gewoon omdat er bepaalde keuzes zijn gemaakt, ook qua backend implementatie. En daar wordt natuurlijk ook het nodige goed in de gaten gehouden. Ik heb nog een hopelijke slimme vraag. Dat weet ik niet zeker, maar dat gaan we nu merken. Er is Objective-C en er is Swift. Nou goed, dat heb je natuurlijk net al gezegd. Maar er is ook iets als een ABI compatibility. Ik weet niet of je daar iets over kunt zeggen, maar wat mij opviel, zeg maar, omdat ik develop meestal gewoon altijd tot net. En als er dan nieuwe versies komen, dan is het ja, oké, er komt gewoon een nieuwe versie, ga met de banaan, niks aan de hand en tot een bepaalde hoofd is er een bek op de compatibility, op de framework en in bepaalde applicatiedraad nog. Maar goed, dat is allemaal redelijk duidelijk en dat is niet zo heel, heel spannend, zeg maar, om naar een nieuwe versie te gaan. Alleen, ik zie iedere keer, oh, Swift 3, ABI-stabiliteit, bla, bla, bla. En als je, die term hield ik nooit rekening mee. En het is wel heel logisch, het geldt voor alle talen en platformen. Maar kunnen jullie, of heb jij in ieder geval iets uit te leggen over wat een taal überhaupt is? Er is een tijd geweest dat je als developer op het Mac-ecosysteem echt helemaal knettergek werd als er weer een nieuwe Swift versie uitkwam, want je kon dan vervolgens je hele codebase weer eigenlijk gaan aanpassen. Dat was eigenlijk gewoon van, ja, sorry, de sprint, die gaan we niet halen, want we moeten nu even alle breaking changes van Apple moeten we eventjes gaan oplossen. En dan had je gewoon inderdaad een paar dagen werk aan. Dus ja, alles wat je in je sprint had staan, ja, doei, dat ga je nooit halen meer. Ja, en wat is daar de oorzaak van? Volgens mij, we zitten nu op Swift 5, geloof ik. Ja, Swift 5. En ze hebben nu sinds een jaartje, geloof ik, vorig jaar hebben ze, pin me niet op de exacte visie, maar ze hebben sinds een jaartje ABI-stabiliteit. En wat dat dus eigenlijk betekent, is dat, ja, waar staat de afkorting eigenlijk voor ABI? Ja, volgens mij het binair formaat, zeg maar. Ja, het is binary interface, maar ik weet even niet waar die A voor staat. Het komt er eigenlijk op neer, dat als je ABI-stability hebt, dan maakt het eigenlijk niet uit met welke compiler je het compileert, dus welke Swift-versie. Het zal draaien op de runtime-omgeving die gebruikt wordt. Want wat zag je ook tot, wat zag je op een gegeven moment ook als eindgebruiker, kun je het misschien gezien hebben, want er is een moment geweest dat in één keer alle apps op de App Store, dat die gewoon zo'n 20, 40 MB kleiner werden. En dat was dus omdat gewoon die complete Swift runtime niet meer in de app meegepakt werd, maar dat die gewoon op je toestel draait. En daarom was het zo'n groot ding dat die ABI-stabiliteit kwam. Want ten eerste, het is wat makkelijker voor de developers, maar voor de eindgebruikers schilder je een boel bandraten. En Apple heeft bewust gekozen om die stabiliteit een tijd lang niet te bieden, omdat ze anders tegen ze houden in het kunnen ontwikkelen van de taal Swift. En op een gegeven moment hadden ze iets van na vier jaar of zo, van nu is Swift voldoende uitontwikkeld. Voorzien we niet hele grote breaking changes meer, dus hebben ze aangegeven van nu hebben we ABI-stabiliteit. En zullen de wijzigingen op dat gebied heel wel overwogen en goed doordacht gedaan worden. Dus het kan nog steeds wel zijn dat er een keer een breaking change zal zijn, maar ze kiezen er nu wel voor omdat in ieder geval forward compatible te hebben. Dus als je een nieuwe versie hebt, dan in ieder geval een oude versie, gecompileerd dat die gewoon wel blijft werken. En andersom geven ze geen garanties hoor. Je moet altijd de nieuwste Xcode gebruiken volgens Apple. Oh zo. Application Binary Interface. Dat kan ik nu heel wijs zeggen. En wat is dat een Application Binary Interface? Je hebt eigenlijk je operating system, dus iOS, en je hebt jouw code, dus jouw programma. En wat dat Application Binary Interface is, dat is eigenlijk het contract wat er op heel laag niveau leeft tussen het platform waar je op draait en jouw executable. Want je kan je voorstellen als jouw executable, als die een functie wil aanroepen om iets naar het netwerk te doen, dan moet die dat wel kunnen aangeven aan het operating system. En wat dat ABU dan eigenlijk voor je regelt, is eigenlijk dat het is beschreven wat waar staat, dus dan kun je die functie aanroepen. En als je een breaking change in je ABU compatibility hebt, dan is het adres gewijzigd van de functie. En probeer je beste vriend meest te vinden als die niet vertelt waar hij naartoe verhuisd is. En dan heb je een probleem. Ja, ik begrijp me. Dat heb je in principe met Windows, de DLL. Die hebben natuurlijk ook een formaat. En op Linux wil ik het zo even kunnen zeggen. Linux heeft ook een naam daarvoor. Dus dat zijn ook allemaal indelingen. Dat was echt wel lang geleden. Dat is toen ook nog wel wat wijziging geweest. Alleen, wat mij opviel is dat dat die indruk, dat binaire formaat, zeg maar, dat die heel erg gekoppeld zat aan de versie van de taal. En ik dacht van ja, goed. Niet de versie van de taal, de versie van de compiler die eronder zit. Ja, maar goed, dat werd gekoppeld voor oké, de Swift 5. En misschien is daar nog weinig een ontkoppeling. Dat weet ik dus niet genoeg. De koppeling tussen de taalversie en de compiler, die is redelijk één op één. Dat wel. Ja, ja, precies. Dus je zou zeggen, ik kan er wel over net spreken, maar dan heb je de runtime, zeg maar, dat is eigenlijk een soort van virtual machine, zeg maar, waar de applicatie op uitgevoerd wordt. Zelfde als bij Java. Dan zit er de bytecode, zeg maar, die dan daarop draait. Die is gewoon stabiel. En dan kunnen een versie van C Sharp 7, 7.1, 7.2, 7.3, die draaien allemaal nog steeds op diezelfde runtime, zeg maar. En die runtime verandert zich sowieso al veel minder snel dan de taalfeatures. Dus dat is helemaal in het begin, dit is echt helemaal een saai ding, de taal C Sharp en VB.NET, die ondersteunde geen generics in versie 1. Ja, dan moet ik even heel goed opletten, dat is 1.1 met 1 of 1.2. Volgens mij in 2.0 kwam generics, maar de runtime, die ondersteunde het wel. Daar kon je wel generics mee doen, maar de taal ondersteunde het niet. Dus dat was even een, ja, ik denk, oh, oké, dat is logisch, want er zitten ontkoppelingen in. Maar goed, dus daarom had ik altijd zo van, oké, hoe zit dat nou bij Apple? Omdat Apple toch altijd net het wat anders doet. Want die dingen van Java en .NET, die lijken heel veel op elkaar. Apple heeft best wel lang nodig gehad om die abi-stabiliteit aan te kondigen. En dat schijnt een hele bewuste keuze te zijn geweest van hun. Nee, begrijp ik ook. Ik bedoel, dat is natuurlijk wel... Ik bedoel, je kan wel over wijsneuzen, want dan zullen ze echt wel heel goed over nagedacht hebben. Dus dat is wel oké. En goed, wat je net zei, die interface-beelden. Kijk, de keren dat ik dus Xcode, waar ik in het begin allemaal zo moeilijk over deed, Xcode openen om te kijken, oké, ik ga even een application maken. Dat was voor mij echt wel heel erg anders. Want in... Ja, er wordt altijd heel veel gekscherend gedaan over Microsoft, maar het gemak waar je in VB, en daar later in VB.NET, een UI maakte, dat ging echt nergens over. Je had gewoon een form, je sleepte een aantal knoppen erop, dubbelklik op een knop, en je zat daar in de code, code erbij, en ga met de banaan. En dat waarde heel erg... Ja. Ja, dat is veel declaratiever inderdaad. Dat klopt. Ja. Ja, dat klopt. Dus dat was zeg maar, ja sorry, dat was in eerste instantie, hoe we formulieren maakten, winforms, zeg maar, heette die. En later hebben we, dat was nog niet per se declaratief, dat was echt in code. Later kregen we zeg maar, dus de declaratieven, dat is de XAML, zeg maar, formaat. Dat is een XML-formaat waar je in je declaratief, vergelijkbaar met HTML, UI, defineert. En dat werd dan onder water weer vertaald naar een aantal andere zaken, zeg maar, dat was heel de async geprogrammeerd. Dus dat was best wel een shift, zeg maar. En dat lijkt volgens mij wel meer op, ja, wat er nu mee gedaan wordt met Swift. Zeg ik dat nu goed? Ja, met SwiftUI. Ja, niet SwiftUI. Ja, precies, ja. Ja, ik heb nog niet heel veel ervaring met SwiftUI. Ja, de gebruikelijke tutorials heb ik wel gedaan en daar is ik een keertje van meegeprobeerd. Maar het grappige is wel dat interface-beelden files, zoals cips en storyboards, die zijn ook XML, hè? Ja. Ze zijn alleen niet heel erg leesbaar, zoals... Ja, precies, zoals het eindelijk soort van bedoeld was. Ja, je weet dat je inderdaad gewoon een ervaren iOS-developer bent als je met enig vertrouwen inderdaad een merge-conflict in een storyboard kan oplossen en dat het dan daarna ook nog werkt. Dat is echt wel zeg maar een soort van achievement als iOS-developer. Ja, ja. Oké. Ja. Oké, duidelijk. Saber, ja, nog een vraag? Wil jij hier op een haken weer? Nee, niet direct. Want we hebben een aantal vragen. Ten eerste, ik zie een aantal vragen staan. Dus ga je in gang, als je erin... Ja, nou, goed. Kijk, omdat jij ook net iets zei over security en safety van je appje. Is je mindset bij het maken van zo'n iPhone-client of, ja, laten we daar even bij blijven, heel anders als je met security begint dan als je dat later toevoegt? En hoe kan je dat doen bij iOS? Nou, poeh, waar zal ik eens beginnen? Ten eerste, iOS als platform heeft security aardig goed op orde. Als eindgebruiker, het allerbelangrijkste wat je moet weten is zorg dat je een passcode op je device hebt. Want als je dat hebt, dan zijn eigenlijk heel veel dingen al voor je geregeld. Nou ja, waarom is dat zo? Het is eigenlijk als je een device passcode hebt ingesteld op je toestel, dan wordt daarvan een encryptiesleutel afgeleid en daarmee wordt alles beveiligd op je toestel. Dus als iemand jouw telefoon zou vinden en zo weet je jouw passcode niet, is alles versleuteld, altijd. Ook als je hem gewoon aan hebt staan en je hebt hem alleen niet unlocked. Ja, en waarom is dat? Dat is natuurlijk omdat je met de bekende app-sandbox te maken hebt op iOS. Natuurlijk, dat is veel meer dingen, maar dit is eigenlijk voor developers het meest relevante aspect. Want de app-sandbox, dat is eigenlijk de speeltuin waarin jouw app mag draaien, en daar mag hij dus ook niet buiten komen. Dus dat is een plek waar je dus je instellingen kan opslaan, je kan daar bestanden opslaan, je kan daar eigenlijk gewoon je ding doen, zeg maar. Dat staat op je cashing in en zo. Maar daar kun je gewoon niet buiten komen. Dus je kan niet, je kan eigenlijk niet eens zien wat er buiten die sandbox is. Je hebt gewoon een API waar je mee kan werken en that's it. Het voelt misschien, als je een Linux developer bent, redelijk beperkend, want laten we eerlijk zijn, als je een echte hacker bent, en een hacker in de goede zin, dan wil je weten hoe alles werkt en dan wil je vooral ook gewoon eens een keer gewoon ergens je vinger in steken en kijken of het stuk gaat. Dat kan op iOS natuurlijk wat minder makkelijk. Het voordeel is wel, omdat je dus die app sandbox hebt, dat je dus inderdaad gewoon als eindgebruiker weet dat je spullen redelijk veilig daarop zijn. Natuurlijk is het ook wel zo dat je daar wel afhankelijk bent van wat de software-entwikkelaar doet van het appje dat je gebruikt. Want als je als software developer bezig bent, dan moet je nog steeds wel gewoon, ook al werk je binnen de condities en restricties van Apple, je moet nog steeds wel goed nadenken over wat je doet, want je kan nog steeds gewoon hele domme dingen doen, zeg maar. En waaronder inderdaad gewoon niet goed omgaan met netwerkverkeer. De spullen die echt kritisch zijn voor de privacy van de eindgebruiker, dat je die op de verkeerde manier op slaat bijvoorbeeld, want die sandbox is wel veiliger, maar ik zou daar bijvoorbeeld niet, het BSN-nummer van de eindgebruiker in zomaar op slaan. Dat zou ik echt wel over nadenken hoe ik dat doe, want je hebt nog steeds dat je eigenlijk hetgene waar ik van uitga is eigenlijk een aantal dingen. Als je software ontwikkeling doet, je hebt data at rest, en data die dus gewoon opgeslagen is. Dan moet je bedenken van oké, als ik het opgeslagen heb, is het veilig. Als dit gewoon op straat komt te liggen, is dat oké. Als dat niet oké is, dan moet je natuurlijk maatregelen opnemen, dus versleuteling, of gewoon niet opslaan. En je hebt data in transit, dus dat is gewoon data die je gewoon in het geheugen hebt, of data die je het netwerk overstuurt. Wat je daar dus eigenlijk gewoon als iOS-developer, volgens mij net zoals elke software-developer gewoon moet doen, is gewoon bewust zijn wat je verstuurt, en ook bedenken van, ik heb deze data, maar wil ik deze data überhaupt wel? En als ik die data heb, moet ik hem dan wel vast houden. Want als ik mee heb gedaan waar het voor nodig was, dan data die je niet opgeslagen hebt, kun je ook niet kwijtraken, zeg maar. En er zijn natuurlijk bepaalde middelen in een iOS omgeving waar je gewoon dingen kan opslaan. Je hebt de keychain, die kennen we waarschijnlijk allemaal ook wel als je op een Mac werkt. Er staan al je internetwachtwoorden, kun je daarin zetten enzo. Als iOS-developer kun je daarop, als je daar iets in opslaat, kun je ook aangeven van wat van restrictiestijl op zit. Je kan bijvoorbeeld aangeven als developer van ja, ik wil dat dit niet het device verlaten. Ik wil niet dat dit naar Apple gesynchroniseerd wordt. Of je kan instellen van ja, ik wil dat als de gebruiker dit benadert, dan moet hij zijn device ownership bewijzen. Dus je devicecode invoeren of je touch ID of je face ID. En dat heeft dan weer met die secure enclave te maken die in Apple devices zit. Dan krijg je gelijk de vraag, wat is de secure enclave? Ja, dat is een soort van ja, dat is een soort van system on a chip die in elke iPhone en elke Mac tegenwoordig zit. Die volledig afgegermd is. Nou, en dan was er nu net wel een paar weken terug dat daar wel weer een of andere security lag in zit natuurlijk. Ja, klopt, ja. Maar dat de path to exploitation van dat ding is vrij bewerkelijk. Dus je bent nog steeds veilig als gemiddelde eindgebruiker. Maar wat dat secure enclave doet, dat is eigenlijk gewoon een system on a chip met een eigen stukje opslag waar dan eigenlijk waar gewoon eigenlijk encryptiesleutels in worden opgeslagen. En waar je dus alleen bij kan komen als je device ownership bewijst. En het ligt een beetje aan hoe je het instelt. Dat mag zijn dat je dat eenmalig hebt gedaan bij het starten van je toestel. Het mag ook zijn dat dat gewoon elke keer dat je het uit wil lezen. Ja, maakt me niet uit. Je moet het gewoon bewijzen nu. Nou, en dat is het betekent dus ook dat je als je op die manier de login van een gebruiker beveiligt. Dus het zit in de secure en je wil Face ID login aanbieden aan je eindgebruiker. Als je dat doet, dus je moet door die secure ankleven en dan doe je het goed. Maar je hebt ook zoiets dat je, hartstikke leuk voor developers, maar dat je gewoon eigenlijk gewoon aan, dat is een API beschikbaar in iOS, dat je kan vragen nou, vraag me naar een eindgebruiker of een Face ID of een touch ID doet en geef me maar true of false terug of het goed is. Ja, en dan als het goed is, als je true krijgt, dan lees ik een waarde uit de keychain en succes, we gaan weer verder. Dan wil je dat, eigenlijk dat beveiligde element, wil je dan echt in die secure ankleven hebben zitten, in plaats van dat het gewoon in de keychain slaat. Ook al is het voor de eindgebruiker, die ziet gewoon hetzelfde. Die zegt ik wil inloggen en bwap, daar krijgt de ding in zijn gezicht van, oh, ik moet even glimlachen naar de camera en je gaat weer verder. Maar ja, dat soort details moet je wel gewoon rekening houden, dat je dus inderdaad je kan dingen over verschillende dingen oplossen, maar ja, je keuzes hebben wel effecten voor ja, waar je data is opgeslagen en hoe veilig het nou werkelijk is. Bij het project waar ik nu dus op werk bij de Achme, ja, is het zo dat ja, dat iOS device hartstikke leuk. We slaan alles zo veilig mogelijk op. Maar dan, er zijn bepaalde elementen aan data die we dus danig belangrijk vinden. Die slaan we dus op met een sleutel die is afgeleid van de gebruikersinvoer, dus de pincode. Nou, en waar zorgen we dus voor? We zorgen ervoor dat datgene wat we afleiden van die pincode, dat is gewoon die gebruikersinvoer met een salt en dat ga je hashen en dan heb je een mooie reeks en bytes, heb je dan wat dan je sleutel is. Ja, die houden we natuurlijk zo kort mogelijk in het geheugen, zodat als we ermee hebben gedaan wat we ermee willen doen en we hebben het niet meer nodig, nou, weg met dat ding, want ja, eigenlijk in security is eigenlijk alles wat met security te maken heeft, dat is eigenlijk radioactief afval en je bent het liever kwijt aan rijk, zeg maar. Ja, precies, ja. Tuurlijk, als je gewoon een leuk appje schrijft die gewoon wat leuke dingen doet voor de gebruiker, ja, dan kun je er misschien een heel anders mee omgaan dan als je daar inderdaad je bank- of verzekeringszaken mee doet. Ja, ja, dat is wel wat kritischer. Ja, natuurlijk. Ja, en alles staat of valt natuurlijk met hoe goede PIN-codes, hoe goede wachtwoorden hier gebruikt. Want je kan echt nog steeds gewoon Fort Knox hebben, zeg maar, als huis, maar als je je PIN-code op een poster op de voordeur plakt, ja, hallo, doe effe niet, dan gaat het er vrij makkelijk mis. Ja. Ja, maar dat spreekt eigenlijk ook. Ja, goed, dat spreekt voor zich, dat blijft. Hoeveel mensen ken jij met een device PIN-code van 0000? Dat zijn er veel hoor. Let maar eens op, als mensen hun device inlokken met een PIN-code, hoe vaak je ze ziet, dat ze gewoon op één saai weer tik, tik, tik, tik, tik doen. Dat is echt wel grappig om te zien. Ja, dat klopt, dat is wel een ding. Nee, die begrijp ik al, maar goed, het is op zich wel, ik denk dat mensen niet eens zich zorgen maken om de bankzaak, want dat denken ze misschien niet per se aan als ze over die PIN-code nadenken, maar ja, weet ik veel dat je niet wil dat als je hem achterlaat dat jouw collega lekker even je WhatsAppjes uit kan lezen of dat soort dingetjes vinden mensen misschien nog veel erger. Ja, dat klopt. Mensen dat bedenken zich makkelijker dan dat ze denken, oh, wacht even, maar mijn bankier is misschien niet veilig als ik dit zo doe. Nou ja, je merkt wel vaker, mensen, als ze er gezichtsverlies van leiden, dan is het vaak toch wel een dingetje en als ze er niet over nadenken, dan maakt het inderdaad niet zoveel uit. Ja, je zei net ook, ik werd een beetje getriggerd, want de Cocoa Heads is een community, zeg maar. Klopt. Maar die naam is natuurlijk niet op niks gebaseerd. Kijk, voor mij is dat, ja, ik heb dat ooit eens gehoord, maar ik denk dat niet iedereen weet wat Cocoa überhaupt is. Ik zie wel verschillende termen langs Cocoapods, zeg maar. Maar kun je vertellen sowieso wat Cocoa is en daarin in het verlengde, wat Cocoapods voorstellen. Ja, het is eigenlijk... Ja, oh ja, sorry, ja. Cocoa, dat is eigenlijk gewoon als je die hard Mac developer bent, dan is dat eigenlijk de user interface library die je in AppKit gebruikt. En AppKit is dan eigenlijk een beetje het algemene user interface framework voor op de Mac. Nou, Apple heeft daar natuurlijk ook een iOS variant van geschreven, die heet UIKit. En die user interface stukken erin, dat valt een beetje onder de noemer Cocoa Touch. Ze hanteren die naam Cocoa niet meer zo heel veel tegenwoordig, maar dat is de origine daarvan. En het is eigenlijk, ja, Mac developers hebben een beetje de neiging, en iOS developers ook, om alles wat maar een beetje met user interface te maken heeft, of in ieder geval een beetje idiot zijn over development op de Mac. Cocoa, whatever. Cocoa Pots, Cocoa Touch, Cocoa Heads, zeg maar. En als je dan naar dat Cocoa Heads kijkt, het bestaat al vrij lang, nog van voor dat ik met app development in aanraking kwam. Was het eigenlijk al gewoon een soort van ja, meetup, los, vast, een beetje zoals de HCC, misschien wel. Dat je van, ja, ik ben een vakidioot, ik heb er zin in, ik wil andere mensen zien, en het moet een beetje een naam hebben die voor de inkrouwt een beetje laat zien waar het over gaat. Cocoa Heads. Dus je bent gewoon Cocoa-minded, zeg maar. En daar komt het vandaan. Dat waren meetups maandelijks, en toen dat nog mocht, wat voor aantallen moeten we dan denken? En was dat dan Amsterdam of Utrecht? Dat Cocoa Heads komt uit Amerika, en dat was inderdaad een beetje een hobbycomputerclub, en dat is tien jaar geleden door Pieter Robinet, is dat hier in Nederland begonnen, want ja, er was een expat die uit New York kwam, en die kwam in Nederland en had zoiets van, ja, ik wil mensen leren kennen, we hebben dat eerder gehoord. Ik ga meetups organiseren, goh, dat is toch wel een bekend onderwerp in deze podcast, heb ik het idee. En die is daar toen mee begonnen. En, nou ja, ik ben er desto ooit een keer ingerold, en ja, we hebben nu dus eigenlijk meetups, als we ze in persoon doen, dan hangt het eigenlijk een beetje af van de locatie waar we zijn, want ja, we kunnen tien man bij elkaar krijgen, we kunnen dertig man bij elkaar krijgen, we kunnen 150 man bij elkaar krijgen. Want het is op dit moment het bereik van, in ieder geval, van mensen met in ieder geval een interesse die ze aangegeven hebben, dat zit nu ergens in de 1200 mensen, die in ieder geval updates krijgen als we weer een nieuwe meetup organiseren. Ik moet wel zeggen, en dat heeft volgens mij elke meetupgroep heeft dat, het is hetgene waar we eigenlijk het meeste tegen aan het knokken zijn, is het terugdringen van het aantal no-shows, want dat is echt niks zo bloedirritant dat je voor veertig mensen eten hebt en daar dan volgens mij twintig man in dat zaaltje staat, zeg maar, en dat is ja, dat is ja, daar loop ik me echt om op te vreten, en ja, en om altijd eten zelf in de 3 weken lang hetzelfde, zeg maar. Ja, dat wil je ook niet. Je wil gewoon dat mensen komen, of in ieder geval tijdig aangeven dat ze niet komen. Maar ja, over het algemeen, een meetup van CocoHertz is zo'n 30 tot 50 mensen, meestal. En dat ligt aan de locatie. Want wat we doen is eigenlijk, ja, we lopen eigenlijk gewoon alle bedrijven die iets met Mac of iOS die verder maar doen, die zijn welkom. En die bieden dan eigenlijk gewoon hun kantoor aan. Daar gaan we naartoe. Er wordt eten en drinken geregeld en wij regelen een spreker en de locatie die regelt de andere spreker, want ja, die hebben natuurlijk ook een belang bij dat al die mensen binnen zijn. Die willen gewoon contacten krijgen met potentiële nieuwe medewerkers of inhuur. Ja, ja, duidelijk. Oké, grappig. Ik zat op je website te kijken vandaag en toen zag ik daar een blogpost over Xcode met een wat hele handige shortcode keys, dus daar wilde ik je voor bedanken. Ik heb vandaag al tien keer Control 6 in getypt. Ja, die is goed, hè? Ja, die is heel goed, ja. Heb je ook iets tegen Xcode? Nee. Niks? Ik weet niet of ik last heb van Stockholm-syndroom, maar het is wel iets wat... Xcode is wel een acquired taste, heb ik het idee. Het is qua IDA, het ziet er wel allemaal heel slick uit. Het heeft ook wel eens in zijn hele lifecycle ook wel periodes gehad dat het echt gewoon, dat het gewoon niet stabiel is. De derde keer dat je compilert, garandeert een crash. Ja, en dat is natuurlijk bloed irritant. Vooral als dan ook al zijn cash's corrupt zijn en je dan vervolgens weer de eerste vijf minuten naar zo'n indexer zit te kijken die dan bezig is. Maar ja, eigenlijk qua IDA, ik kan er gewoon alles mee wat ik voor ARS development doe, maar het is wel... Soms zit ik ook weleens qua code editing, dan is het gewoon niet handig om dat in Xcode te doen. En dan pak ik bijvoorbeeld Visual Studio Code. merk dat ik met de type af en toe erger van, dan doe je iets en dan is het gewoon niet wat je bedoelt met een copy paste actie of wat ook met die auto tap completion. En dan erg ik me, maar voor de rest is het prima. Ja, wat je wel merkt op dit moment is volgens mij dat de meeste IDA's die echt wel een beetje naam hebben, dus dan heb je over de spullen van JetBrains, Visual Studio en dan niet Visual Studio. Volgens mij is alles Visual Studio Code nu bij Microsoft, toch? Nee, nee, nee. Ja, de gewoon grote mensen, Visual Studio. En Visual Studio. Je ziet dat die qua editing experience in ieder geval, en dan heb ik het niet over alle plugins en helpers en dingen die eromheen zitten, maar dat is qua editing experience wel redelijk met elkaar omparst. Natuurlijk, de shortcuts die liggen anders en je muscle memory zul je niet meenemen. Dat viel me wel op. Dat is wel verbeterd, toch? Het is nog steeds, als je refactoring gewend bent, zoals in de gemiddelde Java IDE of in Visual Studio, daar is niet. Van JetBrains heb je wel app code, ja, je hebt niet zo makkelijk extract method en renaming heb je dan wel van een type name. Dat gaat ook niet gegarandeerd altijd goed als je net een compiler hebt, maar het is wel iets wat, refactoring support is op Xcode inderdaad. Dat is een zwakke plek, maar ik mis het eigenlijk ook helemaal niet, want het is als je gewoon een beetje vlot kan editen en goede finds en replays kan doen, dan lukt het allemaal wel. Je zei net even heel snel app code, want ik wilde me een vraag stellen over een alternatieve IDE voor iOS en Mac development, maar app code is er dus één. Ja, app code is eigenlijk gewoon IntelliJ, maar dan voor alles wat je met Xcode kan doen. Dus daar kun je Mac apps en iOS apps in draaien, alleen het nadeel is wel, om JetBrains app code te kunnen gebruiken, moet je Xcode geïnstalleerd hebben, want bepaalde dingen kun je gewoon alleen maar in Xcode doen. En dat is gewoon, ja oké, dat is zo. En ik merk wel dat Xcode heeft nu wel, zeg maar, sinds Xcode 10, hebben ze wel een beetje zo'n kantelpunt bereikt dat je in mijn beleving steeds minder mensen die helemaal app code minded zijn en absoluut geen Xcode willen gebruiken. Ik zie steeds meer dat mensen, oké, app code hartstikke leuk, maar het gaat allemaal net even iets flotter in Xcode, zeg maar. Want app code is toch best wel vaak bezig met allerlei compiles en indexing en dat soort dingen die echt lang duren. En ja, ik heb het wel eerst een keertje geprobeerd, ook omdat ik met PyCharm gewerkt heb. Dat is zeg maar de Python IDE van JetBrains. Ja, dat probeer je toch eens een keer, want dan denk je, nou, dan kan ik alle dingetjes die ik ken uit PyCharm kan ik dan ook gewoon meenemen naar app code. Maar ja, het is er toch op de enige manier net niet. En ja, het is heel persoonlijk. Ik bedoel, het is niet of je een iOS of Mac developer bent, dan kun je gewoon niet om Xcode heen. Ja, oké. Ik hoor geluid, maar ik weet niet waar het vandaan komt. Of is het bij mij? Dat is niet bij mij. Oké, ja, dat had hij ook kunnen. Ik was al blij dat er niet allerlei rare vogels zijn. Wie zijn jullie dan? Oh ja, dat is ook een beetje pet. Maar goed, er zijn alternatieven en die ken ik niet allemaal, maar je hebt vast van Xamarin gehoord. Ja, hoe wordt daar tegenaan gekeken? Dus vanaf de native developer met Xcode. Want ja, ik zie dat vanaf de andere kant van .NET en Michael de Casa, zeg maar, die de oprichter is van Xamarin. Op zich wel een slimme vent en die ook trouwens ook af en toe is in Swift developed. Maar hoe wordt daar tegenaan gekeken? Is dat heel gek? Ja, Xamarin development is echt anders dan als je, zeg maar, native Xcode of eigenlijk iOS development doet. En je hebt eigenlijk twee soorten reacties die mensen geven. Je hebt echt mensen die Xamarin looser doen. Doe het gewoon echt, weet je wel. Doe het doel nep. En je hebt inderdaad de categorie van ja, oké, het bestaat en ja, het doet het. Niet mijn ding. Ja, en er zijn mensen die natuurlijk gewoon met Xamarin development doen. de grote belofte van Xamarin is natuurlijk dat je gewoon de typische Java belofte hebt. Write once, run op twee plekken dan. Dus op Android en iOS. Ja, en dat klopt. Maar als je in Xamarin een app wilt schrijven die op iOS echt gewoon een goede iOS app is en op Android echt een goede Android app is. Ja, dan kun je eigenlijk net zo goed die beide apps gewoon los van elkaar schrijven. Want hoeveel effort die je moet doen om het op beide platformen echt gewoon goed te laten werken. En ook dat iemand in zo'n app zit en ook echt zo van wat is dit dan? Maar dat het echt gewoon voelt als een goede app. Ja, dat kost gewoon net zoveel tijd. Dus als je gewoon twee codebases hebt en je gaat er gewoon volle bak op, dan denk ik dat je gewoon, ja, minstens net zo snel kan zijn als met Xamarin, zo niet sneller. En dat heeft vooral met te maken dat je met Xamarin, als je wat dingen wilt doen die dus niet zo direct supporten zijn dan moet je zelf, ik geloof dat het Bridges ofzo heet en dat je die moet schrijven, maar dan moet je dus eigenlijk gewoon stukjes platform native dingen gaan schrijven om over te zorgen dat je dat kan exposer binnen Xamarin. En daar hoor je wel, als dat aan de orde komt, ja dan ben je eigenlijk af, want dan voor de meeste developers wordt het toch dusdanig ingewikkeld dat het niet weer voor iets is wat er zo even bij gedaan wordt. Ja, het is weer die 80%-20%. Dus voor 80% kan het best wel fitten, maar als je dan die 20% nog wil bereiken dan kost het weer 80%. En onderhoud. Een typische use case waar ik denk dat Xamarin heel erg goed geschikt zou zijn is inderdaad gewoon voor die in-house applicatie. Het correct functioneren, dat dat belangrijker is dan dat het echt gewoon helemaal op een top goed smoelt in de App Store of in de Play Store. En dan heb je echt wel winst van zoiets als Xamarin, want dan kun je inderdaad snel gewoon naar een in-house app uitpompen die gewoon in ieder geval op veel devices kan draaien en die ook redelijk duidelijk werkt bij de platformen. Ja, en dan, kijk, als je al gewoon een .NET shop bent, ja, dan denk ik dat je wel goede redenen moeten hebben om dan voor een in-house applicatie inderdaad niet Xamarin te gebruiken. Nee, nee, precies. En zo zijn er nog andere varianten, volgens mij zijn er andere... Ja, je hebt React Native bijvoorbeeld, of nou ja, liever heb ik het over, je had React Native. Ja, is dat nog zo? Wat is er nu, want dat hoor ik nu verschillende dingen over, want het was een enorme hype. En ik kon op zich een mooie belofte. Je hebt mensen die inderdaad gewoon webdevelopment doen met React en dat bevalt die mensen goed en dat snap ik, want ja, een web applicatie, ook al is het een single-page applicatie, dat leent zich heel goed voor een reactive manier van programmeren. Misschien een beetje lastig om daar nu een beetje te diept in te gaan, maar het komt erop neer dat dat gewoon een bepaalde manier van software ontwikkelen is. En als een single-page web applicatie past binnen je doelstellingen, dan is React heel erg mooi. Want dan kun je heel snel zijn. Het is een eenduidig platform, het is een goede lifecycle, het is goed duidelijk te doorgronden inderdaad van wanneer nou wat gebeurt, ook als je iets op het scherm krijgt. En met React Native hebben ze datzelfde programmeermodel ook naar Android en iOS en destijds ook naar Windows Mobile willen krijgen. En dat hebben ze ook wel echt wel voor elkaar gekregen. Het draait, je kan apps in ontwikkelen, er zijn ook echt grote apps in ontwikkeld. Facebook Messenger was er een van. Wat wel heel erg typisch is, React Native is dus door Facebook ontwikkeld als platform. Is dat Facebook nog niet zo heel lang geleden een hele Messenger app heeft herschreven naar volledige native apps. En ja, en volgens mij hebben ze het ook nooit in de in de Facebook app zelf gebruikt, weet ik niet zeker. Ik ben geen developer daar geweest. Ik weet wel dat Facebook app ooit ook, zeg maar, of het React Native is, dat durf ik niet te zeggen, maar het was wel een soort van een schil zeg maar, die dan native draait met daarin een webview, zeg maar. En daar zijn ze van los, dat hebben ze achter zich gelaten, want dat vervormde ook vroeger echt je meter. En het probleem, wat ik, ik heb zelf nooit met React Native gewerkt, maar wat ik gewoon inderdaad op mijn netwerken heel vaak hoor, is dat mensen gaan met React Native van de gang en dat gaat als een T-release, ze leveren functionaliteit op als een mallen, zeg maar. En dan komt er een software update van React Native library en moeten ze het updaten en upgraden en hoeveel het hoofdpijn die dan ontstaat is, is toch best wel best wel spannend, eigenlijk. Want ja, je wil eigenlijk gewoon hebben dat, ja, je, eigenlijk je dependencies, daar wil je gewoon zo min mogelijk last van hebben. En je wil niet hebben dat je project gewoon in één keer een paar dagen of nog erger stilvalt, omdat je even wat updates moet doen. En dat is dus echt, dat heb ik al meerdere malen zien gebeuren, dat het met React Native, dat ze dus daar nog breaking changes ook in een API maakte, dat het gewoon niet even meer bij te komen was. Ja, en ja, het voordeel van React Native is dat je het in JavaScript kan doen. Nou ja, nadeel is natuurlijk ook weer gelijk dat het JavaScript is, volgens sommige mensen. Ik ken JavaScript niet goed genoeg om te zeggen van nou, Poe. Ik heb ook weleens iemand horen zeggen JavaScript, dat is eigenlijk gewoon list met een rare syntax, als je het op de goede manier gebruikt. Ik weet ook niet waar die vandaan kwam. Nou ja, dat is niet helemaal gek, zeg maar. Ja, dat is niet helemaal raar, ja. Nee, klopt. Ja, wat je dus wel met React Native merkt is dat het gewoon ja, je moet er wel de mensen voor kunnen vinden en dat geldt eigenlijk voor elk cross platform development. Je moet niet alleen het platform kennen waar je mee werkt, maar je moet ook de onderliggende platformen, iOS en Android, toch wel op een zekere hoogte snappen en kunnen om inderdaad gewoon zeker te zijn dat je dingen echt klaar krijgt ermee. Ja. En het schijnt volgens mij wel makkelijk te zijn om React Native op Android te gebruiken dan op iOS, omdat iOS, dan gaat het het vaker stuk, zeg maar, in de stack. Oké. Ik denk dat het wel duidelijk is dat ik zelf niet heel erg fan ben van cross-platform Ja, maar ik begrijp dat op zich wel hoor, want het is mijn mening. Dus met Xamarin ik ben zelf geen, want ik vond het wel cool, van oh, tof, even kijken wat het nou is. Toen had ik zoiets van ja, dan ga je nooit de echte native experience erin krijgen, want dat is natuurlijk de kwaliteit van wat het platform biedt, dus wat Xamarin gaat aanbieden en de concepten die je in C-Sharp of ja, volgens mij, kunt programmeren, hoe goed zijn die doorvertaald naar AOS en welke functionaliteit van AOS kun je gebruiken. Dus dat telt mee. En ik had al zoiets van nou ja, weet je, haal ergens twee hele goede ontwikkelaars. De ene is heel goed in dus eigenlijk weet je wat jij ook zegt, in iOS development, eentje is heel goed in Android development, en laat die dat doen, zeg maar. En dan een aantal argumenten die je dan krijgt, van ja, maar dan kun je geen code delen. En dan weet je, ja, maar dan heb je bepaalde business code die je dan wilt delen over die twee platforms eens. Ja, dat kan wel. Natuurlijk zou dat ook kunnen, maar ik denk wel, welke business code wil ik dan in die app, stel dat ik een API heb, en daar de business app draaien. Ja, want dat is inderdaad, wat je daar zegt, is wel een punt inderdaad, want je hoort inderdaad, ja, maar ik wil mijn code delen en zo, maar de meeste apps zeg maar op Android en IOS, ja, die ontlenen het grootste deel van hun waarde toch eigenlijk ook wel aan de backend waarschijnlijk. Ja, dat is de meeste business logic. Ja, precies. Ja, mijn ervaring met dat soort oplossingen is eigenlijk, dat het weet je, elke extra laag ertussen zorgt ervoor dat het, dat je iets eerder, dat het gaat wringen. Weet je, dan lukt het net niet en dan moet je in een rare bocht gaan zitten werken, om iets voor elkaar te krijgen waarvan je denkt, nou ja, dit kan niet zo moeilijk zijn. En dat is ook niet zo moeilijk als je niet, als je gewoon bij de native code blijft. En hoe snel het gaat wringen, ja, dat ligt dan een beetje aan die laag. Maar ja, ik ben er wel eens heel snel tegen aangelopen. Ja, dat beviel me niet. Ik zit dan liever dichter op het OS en in dit geval dan Swift Objective-C, dan verder weg. Ja. Ja. Ja, dat is ook, ja, het is een deelsmaak en deels, ik denk ook, als je de case gaat maken, zeg maar, wat gaat het met kosten, even heel concreet. Dus dat ik denk, nou, een hele goede developer van alle tweede platforms, die gaat gewoon echt sneller zijn. En als die een factor twee keer zo snel is, ja, dan denk ik dat die business case heel snel gemaakt is om gewoon die twee mensen in te duren. Maar dan heb je nog, als je zo gaat redeneren, dan moet je natuurlijk ook die mensen kunnen vinden. En dat is ook, ja, maar wat is het? Maar wie vind je makkelijker, de Xamarin developer of de NATO developer? Ik denk dat er minder Xamarin developers zijn dan de NATO developers. En daarbij, wat is, zeker als je snel wil zijn, moet je dan eigenlijk wel willen dat je twee apps tegelijkertijd ontwikkelt. Kun je dan niet beter die twee developers op of Android of iOS zetten, dat die dan eerst gewoon, je gaat gewoon eerst MVP halen. En wat ga je dan de eerste doen? iOS. Ja, dat is heel simpel. De meeste bedrijven kiezen dan iOS. En de reden daarvoor is dat, ja, het schijnt dat iOS gebruikers, ja, de euro's gewoon iets losser in de portemonnee hebben zitten. En dat heeft niet zozeer te maken met koopkracht en dat soort dingen. En niet gewoon zozeer van het inkomen letterlijk van de persoon, maar meer met het gemak waarop je op iOS, je geeft iets makkelijker geld op iOS uit dan op Android. En ik weet niet waarom dat is, want je hebt mensen die zweren bij Android en die wonen in een kast van huis en dan denk je echt van ja, wat loop je nou moeilijk te doen over een appje van 1 euro. En ja, terwijl bij bij iOS zie je toch echt mensen die hebben echt, ik weet niet wat voor apps hebben ze allemaal uit de app store staan, waar ze ooit een keer wat voor betaald hebben. En dan denk ik echt van ja, want het feit wel dat het aantal iOS devices ten opzichte van Android devices die in het wild leven, zeg maar. Ja, er zijn gewoon echt al minder iPhones dan Android toestellen. Elk jaar worden er minder iOS devices verkocht dan Android devices. Ja, ik begrijp het ook. Er waren ook wel meer van die verbazingen. Dit zijn wel hele oude cijfers. Maar als we bijvoorbeeld gingen kijken naar, hoe heet dat? Als je op een web server ging kijken van waar komen de hits vandaan? Dat er dan veel meer iOS device, zeg maar, aanklopte dan Android device. Terwijl Android was er in absolute nummers veel, waren er veel meer van. Dus dat was, ja, ik kon dat niet verklaren, ik had er toen ook geen verklaring voor gekregen. Maar daar zit dus echt wel ander gedrag op, op Android als op iOS. Ik weet niet hoe dat nu is. Het is op zich wel iemand die gewoon de flagship phone van Samsung koopt. Ik denk dat je die wel redelijk kan gebruiken, vergelijken met de persoon die de flagship phone van Apple koopt. Je hebt alleen wat minder keuze bij Apple, natuurlijk. Allewel, je kan nu kiezen tussen een mini, normaal en pro, geloof ik, en ook nog meer. Ja, precies. Je kan nu uit vier dingen kiezen, en wat kleurtjes. Maar bij Android is het ook gewoon, ja, daar heb je Samsung, en wat is nog meer de grote op dit moment? Ja, volgens mij, LG, ik weet niet hoe groot die zijn. Huawei was heel groot, maar dat is echt helemaal ingekakt, natuurlijk, nu. Ja, door de ene of andere oranje vent. Hoe heet het? Ja, precies. OneNote, de OnePlus, nee, hoe heet dat ding? One plus two, ja, whatever. HTC? Nee, niet HTC. Het is een Chinese merk, Apple is het moedermerk. En voor de Europese markt, hebben ze de OnePlus. Nog iets. Ja, nog wat. OnePlus, nog wat. Het zijn net van die codes die ook achterop op dure auto staan. Ik zie hier 640 staan, maar er zit niet de 6,4 liter in. Hoe zit dat nou? Nee, precies, ja. Nee, maar goed, die was in eerste instantie, die was de prijsprecentatie was heel erg goed, zeg maar. Maar je ziet dus, dat vind ik wel grappig. Dat is effe niet per se development, maar je merkt dat er heel veel kritiek iedere keer is op iOS of Apple producten. Maar dat dan uiteindelijk binnen een half jaar of een jaar, dat andere merken dezelfde dingen overnemen. dat was anders, maar de, hoe heet het ding, de notch, zeg maar, is overgenomen. Nou, eigenlijk, kijk, de hele touch screen is natuurlijk ook hoe dat nu, dat Apple met iPhone als eerste was en dat de andere het overname. Dus dat, ja, dat vind ik dan wel weer opvallend. Dat had wel een beetje, ja, geklaagd wordt over Apple, maar andere nemen het ook over gewoon. Ik vind die hele strijd niet zo interessant. Ik zit prima in mijn ecosysteem. Ja, wat je wel ziet met, dat merk ik uit mijn omgeving in ieder geval, is dat je nu steeds meer hoort van, ja, weet je, mijn iPhone 11 of mijn iPhone 10, die is nog goed genoeg. Ik hoef die 12 niet, ik wacht nog wel een jaar. Ja, de ontwik van de devices. Ja, wat is nou nog? Hoe nieuw en schokkend is het nieuwe en schokkende van de nieuwe iPhones? Ja, het grootste nieuws van de iPhone dit jaar is dat er een iets kleinere versie is. En verder, ja, hij is sneller en een betere camera, maar hoe goede camera moet je hebben, uiteindelijk? Ja, ik deed het eerst iedere twee jaar upgrade ik. Maar ik heb nu een iPhone X, de iPhone 10. En ja, dat ding was, dat is sowieso, volgens mij, in één keer een veel dure telefoon. Want ik had ook die, ja goed, die 256 gigabyte. Dat ding was echt belachelijk dure. Want al had ik al eens iets van, oké, misschien dat ik met deze iets langer ga doen. En ik zie eigenlijk, nu ik de nieuwe, ja, los van het design is wat anders, heb ik niet zoiets van, oké, ik moet nu per se de nieuwe hebben. Dat heb ik echt al, ja, dat heb ik gewoon niet meer sinds een jaartje of twee, drie. Komt het nou omdat we kinderen hebben? Nee, ik heb dat heel lang niet. Nou goed. Wat ik ook merk is, als ik een Xcode test, dan kies ik gewoon de kleinste oude telefoon in mijn Simulator. Want als het daarop past, dan heb ik in ieder geval ruimte genoeg. Ja, dat wordt nog wel een dingetje op de iPhone mini, want die schaalt eigenlijk alles wat er op een iPhone 12 getoond wordt. Op een iPhone 12 mini wordt het allemaal iets kleiner weergegeven. Dus dan moet je... Dat wordt voor de leesbaarheid nog wel een usability dingetje, denk ik. Want het is heel typisch. Wie kopen over het algemeen de kleinere toestellen? Zonder gelijk weer te stereotyperen, want ik weet dat we het over community guidelines en zo gehad hebben op deze podcast. Maar de kleinere toestellen worden toch vaak door dames en oude mensen gekocht. En waarom is dat? Ja, zo'n enorme roeispaan past niet in je broekzak. Want ik weet niet of je het wel eens vergeleken hebt, hoe groot een broekzak van een herenbroek is vergeleken met die van een damesbroek. Het is echt belachelijk. Dat past bij mij, in mijn broekzak, past gewoon vier keer zoveel als dat bij mijn vrouw in de broekzak. Wat wel grappig was, zeg maar, toen de iPhone... Er was toen een trend, dus al die telefoons werden groter. En Apple die bleef maar hangen op Ik weet niet, rond de 6 of zo, die was allemaal wat kleiner. En toen kreeg je in een keer de 6... Is dat de 6 Plus of de 6S Plus? Weet ik veel, de grote. Ja, op een gegeven moment had je de Pro en de Pro Max en dat je echt denkt, wat zijn die namen joh? Dat je echt denkt, wat? Maar het werd echt groter en dat was echt een soort van statussymbol. Je zag dus juist een vrouw, want je zegt ook van een vrouw kleiner, maar die vrouw die liep altijd met zo'n hele grote, zeg maar. Ja. Volgens mij moeten we ook oppassen dat we niet al te veel generaliseren en opmerkingen maken. Nee, het was niet generaliseren, maar dat merken ze. Dat hebben ze onderzoek naar. En bijvoorbeeld ook in China zeg maar, was het een statussymbol, dus die grote verkocht gewoon beter, gewoon puur om te kunnen laten zien, kijk, ik kan die de duurste en de grootste kan ik betaal, terwijl ik heb de 6S Plus, die heeft mijn zoontje nu, ze slaapt eigenlijk ook nergens op. Als ik dat ding vasthoud, denk ik, ja dat ding is gewoon te groot. Weet je, ik had zoiets van, ja, ik kwam toen van een 5S, dat formaat vond ik echt goed. En toen dacht ik, ja, oké, nou ja, Apple gaat groter, zeg maar, en dan weet je, als ik dan toch groter ga dan, dan my all the way. Dat sloeg helemaal nergens op. Zo groot dat je broek ervan afzakt inderdaad. Ja, echt. Dat ding was eigenlijk helemaal niet praktisch. Die kon je niet in je broek dragen. Had je gewoon een tasje nodig om hem mee te nemen. Ja, ik vind de iPhone 10, die ik nu heb, dat vind ik op zich een goede goede grootte. Ik moet alleen uit mijn hoofd praten dat ik niet de Pro Max of whatever dat ding ook heet, ga kopen omdat dat ding een iets betere camera heeft. Je zei net van ja, wat maakt die camera uit? Maar ja, goed, ik maak best, weet je, de kinderen maken wat foto's van. Ja, iPhone camera is de meest gebruikte camera in de wereld. Ja, dat klopt. Dus dat is echt wel grappig. Ja. Even kijken. Ik weet niet of wij nog andere vragen willen stellen. Heb jij nog iets, Bernard? Nee, ik denk dat we een leuke overview hebben gehad over iPhone ecosystem en ontwikkeling. We kunnen wel, nou ja, laten we dat niet doen, de diepte in gaan op patterns of wat ook. Tijd voor een rant, of niet? Ja, dat is een hele goede. Saber. Heb ik daar, ik heb geen mooie rant, jingle. Ja, dat is een nieuw onderdeel. Ja, dat is een nieuw onderdeel. Ik heb gewoon geen... Geen jingle? Nee, geen goede. Die airhorn, deze die... Dat is geen rant. Maar ja, je kunt wel aankondigen. Rant, ik heb niet zelf eentje, volgens mij heb ik daar zelf geen gevonden. Ik zag wel dat Jeroen een tweet aanhaalde van Emily Kager. Kager is ook in het Engels. Kager, ja. Ik zag er zelf sowieso een aantal keer langskomen en ze had, dit ging over, je moet me even korrigeren, want het ging over een TikTok video, die wordt alweer gepost op Twitter, ingewikkeld. En daarin speelt ze een soort van job-interview van een arts of een chirurg, die wordt ondervraagd. En dan vragen ze ook van, hey, maar... Je opereer je ook in je vrije tijd. Je opereer je ook in je vrije tijd. Dat die anderen denken, oh, zo. En dat een beetje om te vergelijken met, hey, waar de developers dan om gevraagd worden van, hey, hoe zit het nou? Waarom moet je in je vrije tijd nog werken, zeg maar, gratis en voor niks? Maar dat zei jij ook, van, ja, ik ging ook die replies, zeg maar, even checken. Een aantal waren gewoon, denk, oké. Ja, die waren ontoppen, zeg maar. Ja. Nou ja, er zaten ook, op het eerst diegene die ik zag, was ook van, nou, ja, hoezo? De vergelijking is niet helemaal oké. Het was al een beetje mansplaining, werd het al een beetje. Toen dacht ik, ja, oké. Nou, van allerlei dingetjes. Maar ik weet niet welke dingen jou opviel. Nou ja, wat me vooral inderdaad opviel, was dat inderdaad alles werd gelijk weer ontkracht van, ja, dat is niet zo. En inderdaad, wat je al zei, mansplaining inderdaad, dat je echt denkt van, gast, ben je dom of doe je dom? Ja, precies. En iemand die reageerde, ook weer van, ja, vervang die arts maar gewoon met elk beheerdekeurig ander beroep en het klinkt nog steeds net zo belachelijk. Ik bedoel, het timmerman, die zit ook niet in zijn vrije tijd te timmeren, zeg maar. Ja. En want het hele idee van die video van die dame was dat het eigenlijk best wel raar is als je een software developer bent, dat dat dan eigenlijk ook gewoon het enige en het alles is wat je doet. Want dat het eigenlijk, want je ziet het best vaak dat inderdaad software developers wat hebben die als hobby? Software development. Ja, denk ik. Terwijl heel veel andere mensen, die hebben wel een hobby naast hun werk, was dan eigenlijk het punt van die video. Dus waarom zouden software developers dan dat niet mogen hebben? Want dat is natuurlijk ook een beetje de Amerikaanse cultuur, denk ik dan. Want daar werk je en dan werk je gewoon helemaal op het schompus. Want oh jee, als je de baan kwijt raakt misschien ofzo. Maar ja, dan je zou dan volgens blijkbaar sommige partijen geen goede software ontwikkelaar zijn als je daar niet 80 uur per week mee bezig bent. Ja. En dat was een beetje het punt dat gemaakt het. Maar het ging in die hele commentary het gelijk over zoveel andere dingen. Ja, nou goed. Ja, maar ze maakt er wel een grap over. Ja. En mensen namen het gewoon echt serieus. Ja. Ja, maar ook gewoon van, ook één kritiekpunt was ook van ja, waarom doe je dan zo'n filmpje? En waarom doe je dat dan gewoon met een decolleté in dat ik je BH kan zien? Ja. Ik denk van ja, weet je, als zij dat aan wil en ik weet niet. Ja. Dat is heel raar, dat je echt denkt van kijk, als ik gewoon inderdaad gewoon een iets te diep decolletétje in m'n shirt zou hebben, dan, nou volgens mij als man moet je dat niet hebben, geloof ik. Maar in ieder geval, als je in ieder geval zo'n fitness shirtje aan hebt, dat je gewoon iets te veel borsthaar kan zien, zeg maar. Ja. Ja, daar zal niemand op reageren dan. En omdat je dan een vrouw bent en omdat je oh jee, het komt in de buurt van dat er iets boezem misschien in beeld zou kunnen zijn, is het gelijk een issue. En ook een beetje aansluiten op wat er al eerder in de podcast gezegd had ik echt wel zoiets van, ja, dit is weer echt typisch zo'n voorbeeldje, weet je wel? Ja, ik brouw nu een beetje door die commentaren en ja, dat slaat gewoon helemaal nergens op. Maar ja, het is echt, maar ook echt binnen twee minuten ook gewoon dat het gelijk die kant op gaat. Dat je echt denkt van hoe dan? Ja, goed. Ja, het is ook wel gewoon, ja, het is het internet en het is Twitter. Dat is sowieso een mooie brandbielen bij elkaar, of niet? Ja, het is op zich. Je kunt er met popcorn een keer naar kijken. Ik raak dan wel getriggerd soms. Ik had bijna een reactie gezegd, want dat ding was al een paar dagen geleden ofzo. Wat had je willen typen dan? Is het nog relevant? Nou nee, er was één Nederlandse, die zei dat haar collega's iets hadden gezegd, als ik als man zei, ook iets over die decollete. Als ik die kleren zou draaien, weet ik veel. Ik had een raar comment en toen wilde ik nog zeggen en dat is serieus zo. Toen dacht ik, ja weet je, dat komt niet geloofwaardig over, laat maar zitten. Maar ik had dus echt serieus, dat klinkt heel stom misschien, maar ik had die decollete nog niet door. Daar stonden allemaal tekstjes, zeg maar. Ik zat te lezen, ik had niet eens gezien. Dus ik zat echt serieus te lezen en ik had haar tweet gelezen. Toen dacht ik, oké, dus ik had het filmpje echt denk ik vier of vijf keer gezien, serieus. Dat je echt denkt, valt mensen dat op? Ja, en toen ging ik kijken en ik, oh ja, maar dat was echt nou ja, goed blijkbaar, en als het je dan opvalt, hoezo moet je er dan een heel ding van, maar goed. We doen het nu ook weer, heb je een doel? Ja, inderdaad. Het is wel zo, als man kun je inderdaad gewoon, je kan je spetter aandoen en een spijkerbroek, en je gaat lekker op kantoor aan je bureau zitten. En echt niemand die dat interesseert. Maar moet je het als vrouw gaan doen? Ja, dan ben je gelijk onverzorgd en kleedjes een beetje aan enzo. Ik heb zulke opmerken wel eens van dichtbij iemand zien maken naar iemand. Dat was zoveel jaar geleden, toen was ik echt nog, als ik dat nu zou zien gebeuren, dan zou ik echt zeggen, ja gast, doe van normaal. Gelukkig, er veranderen stap voor stap veranderen wel dingen, ja, het is dus wel maar goed, dat hebben we in eerder podcasts ook al gezegd. Ja, laten we dat niet helemaal weer uitkouwen. Hey, we gaan naar de vorige sectie, developer dilemmas. Oh, ik was er al bang voor. Ja, we hebben er een aantal, je mag niet, ja, je moet kiezen. Het is een binaire keuze. Ja, we kunnen het erover hebben, natuurlijk, maar goed, de eerste, monolithe versus microservices. Nou, moet ik eerlijk zeggen, nou ja, goed, ik heb hier wel een antwoord voor, maar jij mag eerst. Ja, en monolithe neig ik dan naar? Nou, ik vind hem lastig. Bernard? Ja, it depends. Dit hebben we eerder gehad en dit kom ik bekend voor. Ja, klopt. Ja, ik zou het ook zeggen, want het is mag niet. Ik ben niet. Ik ben niet van de de omdat het de hype nu is microservices van oh ja, dan microservices is de betere. Er is niet de betere, zeg maar, en ja, die je kiest en ik kan heel goed begrijpen, want de argument om een monolithe te nemen, ja, dat is minder complexiteit. Het grappige is wel, want kijk, uiteindelijk als je microservices architectuur neerzet, dat is wel gewoon een samenhangend geheel en het hele geheel wat je schrijft kan niet zonder elkaar. Dus uiteindelijk het systeem is nog steeds een monolithe, alleen hoe je het in deelt en waar het draait is misschien iets anders. Ja, maar goed, het is een microservices gaat vooral over het ja, het deployment aspect, zeg maar ook, dus dat je het los van elkaar kan deployen en dat het afgebakende kleine systeempjes zijn die onafhankelijk van elkaar kunnen werken. Dus dat is dan wel anders, zeg maar. Ja, dat je ook volgens mij met microservices is nog heel belangrijk dat je infrastructuur in code uitdrukt, toch? Dat is, zeg maar, om het makkelijker te beheren, zeg maar, om het beheerbaar te houden. Daar ga je dan wel heen. Kijk, als je alles met de hand gaat deployen, ja, dat werkt. We kunnen steeds spreken van een microservices architectuur, maar dat is een ander aspect. Sommige mensen koppelen dat meteen aan dockercontainers en Kubernetes, zeg maar. Je kan het ook op PM-niveau doen. Precies. Dus dat is iets anders, zeg maar. Dus in die zin, ja, ik vind dat is voor allebei is te zeggen. Je kunt binnen een grotere oplossing, zeg maar. Weet ik veel, een 5, 6 systeem. Dat kan best zijn, dat een systeem een monolith is, een ander systeem microservices architectuur. Dus dat kan gewoon, zeg maar. Het grappige is wel, de app waar je kan werken is op zich, een app is een monolith. Dat is per definitie zo. Maar binnen die app hebben we wel op framework-niveau, het zijn een soort modules, hebben we het wel gewoon als een soort van micro-framework architectuur opgenomen. Zodat je dus op team-niveau en ook op functioneel niveau kun je gewoon wel scheidingen leggen. En dat is op zich qua microservices. En ook micro-frameworks is dat wel een voordeel, dat je dus inderdaad van dat je het zo opknipt, zeg maar, is het heel duidelijk waar de contractuele afspraak tussen API's liggen. Dat is niet grijs. Je gaat je runtime uit naar een andere runtime toe, dus daar ligt een contract. En dat is gewoon de API. En dat is wel een groot voordeel, denk ik, van van zo'n systeem, omdat je ze onafhankelijk deploybaar van elkaar maakt, maar ook onafhankelijk van elkaar ontwikkelbaar. En dat is voor wat wij doen. Is dat wel het grootste voordeel wat wij nu merken? Want we deployen nog steeds gewoon als één geheel uploaden naar Apple. Nou, volgende denk ik. Ja, zeker. Mono repo versus multiple repos. Echt? Ook bij microservices? Ja, daar werk ik nu natuurlijk niet mee. Microservices zou je kunnen stellen van wel, maar ook weer niet. Ja, dit is een beetje het voordeel van Mono repo is dat je het geheel wat je deploit, het geheel wat dus een versie is, dat dat gewoon één plek is, één tag. Er is gewoon één punt in tijd op één plek die gewoon juist is. En dat is met multiple repositories is dat natuurlijk niet. En dat is zelfs als je bij iOS development inderdaad een dependency manager gebruikt, CocoaPods bijvoorbeeld, of er zijn nog een paar andere. Je trekt dan eigenlijk gewoon code uit een andere repository ergens op het internet. En dan wordt er in je logfile, wordt dan wel de hash van die commit wordt opgeslagen. Maar uiteindelijk je beschrijft het op een tag niveau. En een tag denken mensen vaak al van in Git dat dat iets heel erg stabiels is. Maar dat is niet. Dat is echt gewoon een tag. Een tag is alleen maar een label aan een commit. We noemen het een tag. Dus ik ben wel het voordeel vind ik wel voor iOS development in ieder geval dat een monorepo dan de versie die je in je app hebt staan is op jouw repository ook gewoon één tag. En die ik heb ook met my third party dependencies ook liefst in die repository erbij inzitten. Ja, maar goed, dat was de discussie. Die hebben we op ons slack ook wel een beetje gehad. Dat is van een EK en ja, branching en weet je, dan wordt dat feestje wordt wel. Ja, misschien wat lastiger, misschien niet zo induid. Dus zeker als je echt los systemen vaker los van elkaar wil. Nee, sorry, maar bij microservice zijn die dingen afgebakend. Er zijn duidelijke contracten tussen die verschillende systemen. Dus dan zou ik het niet in een micros of in één monorepo stoppen en aparte repos per microservice. Maar als het een monolithe is en er zijn meerdere systemen, meerdere applicaties, dan kun je ze wel bij elkaar houden. Want het wordt soms complexer om dan verschillende repos te gebruiken om überhaupt iets te kunnen ontwikkelen. Je zult iets nodig hebben wat het samenstellen van je release inderdaad. Je gaat nog steeds ergens beschrijven van wat bij elkaar gezocht inderdaad je hele complete werkende systeem is. Wat zat er in die release? Inclusief alles wat je erin propt van externe lips, iets voor pots of... Oké, nog twee, denk ik. Eentje? Welke wil je? Volgens mij hebben we die al gehad, die volgende. En deze wil ik ook doen. Misschien moeten we geen doen, want ik vind hem niet zo leuk. hetgeen die we wilde doen was Taps vs. Spaces. Ja, die kan heel kort. Het zat me echt... Nu, wacht even, sorry. Het was eerst... Het boeide me echt niet. Als ik in een team kom en we zitten met vijf man die andere vier zeggen we doen Taps, dan zeggen we oké, doen we Taps. Dus doen we Spaces? Ja, dan doen we Spaces. Want die IDA's, die zorgen dat het wel weer goed komt. En ik hou me gewoon aan wat de rest van het team als standaard heeft. Per zelf had ik nooit een voorkeur. Wat iemand wel zei is dat als je Taps gebruikt, dan heb je de mogelijkheid om te zeggen oké, in mijn IDA is één Taps visueel zijn het vier Spaces. Of één Spaces. Wat jouw eigen voorkeur is. Terwijl het gewoon als karakter is getypt is het één Taps. Dus dat is wel iets wat je wel met Taps kunt doen, met Spaces niet. Want dan moet je al die Spaces gaan vervangen door. Volgens mij, was dat niet een discussie van iemand die slechtziend was? En dat voor hem heel veel uitmaakte als hij ging oplezen ofzo? Dan kon hij het echt veel beter zichtbaar maken als de Taps stonden in plaats van Spaces. Dat snap ik. Toch kies ik Spaces voor mezelf in mijn eigen project. Ik kies eigenlijk ook altijd wel Spaces. En het klopt inderdaad, je IDA die helpt je wel. En als je echt in een omgeving komt dat het heel specifiek iets anders is dan zet ik zelfs mijn accoladen wel op dezelfde regel in plaats van de volgende. Ja... echt... ik kan er niet zo heel op punt van maken. Als het maar binnen het team een beetje oké is. Ja, als het in de CodeBase zelf maar op één manier gedaan wordt. Anders word ik gek. Ja, dat wel. Daar heb je wel een punt. Dat klopt. Oké. We hebben blijkbaar, ik weet niet of dit is wel een tricky ding. Misschien. We kunnen nog wat weggeven. Dat volgens mij wel. Ja, daarom. Dus vorige keer hebben we een aantal codes gekregen voor manningboeken. Die zijn nog niet allemaal vergeven. En nou is het grappiger. Kijk, als het tussen nu en dat gepubliceerd is dat ze wel vergeven zijn, dan is dit stukje de rest van de wereld niet te horen krijgen. Als het nog niet zo is, dan blijft dit er mooi in. Er is sowieso één-één discount voor 35% korting op manningboeken. Die code kun je krijgen via onze Slack. Dus dan moet je maar naar onze Slack komen. En de andere is een prijsvraag. Die was in de vorige aflevering. En de vraag was, dan moet ik het even uit mijn hoofd doen, is in welk land heeft Pauline geprogrammeerd? Dat was de vraag. Gewerkt. Sorry, sorry. Het is veel te laat, joh. Ik ben al helemaal niet meer scherp. Maar goed, dat dus. Ja, en als je een antwoord hebt, dan kun je één van ons, Kishen, Bernard, Johnny, Pauline of mij een DM-tje sturen en dan gaan we kijken of je het juiste antwoord had. En op tijd, ja, want er zit nog wel een soort van deadline. Maar goed, als je te laat bent, dan heb je pech. Oké, ja, er is nog één ding. Ja, we maken ook wel wat kosten in deze podcast. Nou is het niet zo dat ik meteen allerlei mensen vraag om geld te doneren. Kan, mag, maar dat is niet waar ik op uit ben. we nemen nu weer, vanwege corona nemen we online op en we gebruiken daar de tool Zencast ervoor. We worden gesponsord. En Salves Test Services die heeft een donatie gemaakt zodat wij Zencast kunnen gebruiken. Op de kosten van, daar betaalt Salves voor. Dat is heel fijn. Shout out naar Salves. Ja, dank je wel. Werkt goed hoor. Ja, dat gaat. Ik hoop dat het nu helemaal vast. Hoor je mij? Ja, precies als je de gode verzoekt. Goed. Dat was hem weer eigenlijk. Wil je nog iets zeggen ter afsluiting? Heb je nog een tip voor de ruitse knallen? Of iets anders? Ja, dat is een hele goeie. Sorry dat ik je onderbreng. Ik ga er wel snel overheen, want we doen normaal sproken tips en boekentipsen. Dus als je een tip hebt, dan is het... Dat is voor de iOS developers dan een beetje specifiek. Maar er is een podcast die kun je ook vinden. Dat is de iOS Lead Essentials. Dat is als je een lead developer of senior wil worden. Ik denk ook wel als je sowieso een developer bent. Dat zijn twee gasten. Dat is echt supergoed. Ze zijn wat lastiger te vinden op het internet, want je komt dan gelijk in hun web van sales terecht, zeg maar. Maar dat is echt een goeie podcast om eens een keer te luisteren. Als je gewoon eens wat getriggerd wil worden over ja, hoe ben je senior? Hoe help je mensen in je team bijvoorbeeld verder? Dat is toch vaak wat heel onderschat wordt. Een lead developer is over het algemeen wat minder met code bezig, helaas. Ik vind ergens wel jammer. Ik schrijf gelukkig nog steeds meer dan de helft van de tijd code. Maar een van de hele belangrijke aspecten van een lead developer is ook dat je gewoon kijkt wat er binnen je team rondloopt. En hoe je eigenlijk die mensen verder kan helpen. Gewoon als persoon, maar ook gewoon vooral als developer. ja, ik streef er altijd nadat als ik met iemand samenwerk, ja, tuurlijk, het maakt me wel uit of ze gaan of dat ze blijven. Een fijne collega natuurlijk, iemand waar je lang mee wilt samenwerken. Maar ja, als ze dan ooit een keer vertrekken, dan hoop ik toch echt wel dat ze terug kunnen kijken van ja, ik heb hier zoveel geleerd. En als dan ook nog mijn naam erbij onthouden wordt, dat zou ik echt heel gaaf vinden. Dat iemand gewoon ook echt met een fijn gevoel terugdenkt aan het samenwerken met mij en nou ja, echt dat je samen dingen gedaan hebt, maar dat je ook iemand het gevoel hebt gegeven dat ze gewoon zonder heel erg die maximale druk erop te hebben, maar dat je wel gewoon de uit hebt gehaald wat erin zit, zeg maar. Cool, heb je de URL? Als je die doorkopt, dan kom je die in de show notes. Ja, die komt zeker in de show notes. Ja, oké, dan komen we later met die URL. Cool. Ja, ik heb geen tips. Nee, ik kan alleen bedenken lees de stripboek The Watchman, maar ja, dat is altijd een goede tip. Ja, dat zeker. Die moet je echt lezen. En de Pregmatic Programmers 20th Anniversary Edition is ook nog wel goed. Ik weet niet. Als ik een junior in mijn team krijg, dan krijgt hij die cadeau. Ja, heel goed. Ja, dat is sowieso wel. The Watchman, joh. Ja, je zegt nu The Watchman, joh. Heb je Providence? Ken je dat van hem, Alan Moore? Nee, ben ik ook benieuwd naar. Die wil ik ook wel, want Alan Moore heeft The Watchman. Die heb ik nog niet. Maar Vivo van Dert heeft ook een hem. Die heb ik allebei, maar die Providence ben ik nieuwsgierig naar. Maar die is nieuwe of niet? Die is heel recent, in de laatste 10 jaar. Oh, oké. Ja, ja, ja. De serie is ook een tip trouwens, maar dat moet je maar... Ja, die wil ik eruit zien. Ja, die moet je echt zien. Want die is echt heftig. De film vond ik niet zo goed als de serie, want de novel is heel erg goed, maar de film, ja, het is wel mooi gefilmd en zo, maar het doet het verhaal geen recht toe, vind ik. Oké, goed. Genoeg daarover. Dit was hem weer. En ja, zoals altijd, als je niet geabonneerd bent, dan moet je abonneren, maar ik denk dat als je zover bent gekomen als nu, dat je denk ik wel al geabonneerd bent. Dat is gewoon... En zo leuk is dit gewoon, dat kan niet anders. Ja, we zouden het heel leuk vinden als je nog niet op onze Slack bent geweest, dat je, ja, kom naar onze Slack, het wordt steeds gezelliger. Daar is trouwens je roen ook te vinden. ik denk met iets minder berichtjes nu, want ik was aan het bijluisteren met alle afleveringen, dus ik had op elke aflevering heel veel te merken, geloof ik, qua inhoud of dat ik nog een discussie opstartte. Ja, ga dus naar onze site, codekelets.nl, daar kun je gewoon de links vinden om te subscriben met je favoriete podcast-app of om bij onze Slack te komen. Dus dat zijn al de links. Je kunt ons vinden op Twitter appstaatje codekelets en LinkedIn. Dan moet ik trouwens wel een beetje mijn huisweg weer wat meer doen, om te zorgen dat we wat meer berichtjes uitdoen. En een nieuwtje is dat er ook een nieuwsbrief gaat aankomen. Die gaat op de site zichtbaar zijn, dus de hele tijd dat dit gepublished is dan staat die link erbij. Het idee is dat er iedere twee weken dat er een nieuwsbrief uitkomt, met gewoon nieuwtjes en wat interessante links, zeg maar, voor software-ontwikkelaars. Een klein beetje duiding en goed dat je even in een korte tijd even een aantal nieuwe, interessant onderwerpen of GitHub-repositories die nuttig zijn dat je die even voorgeschoten krijgt. Even zien hoe dat gaat. De eerste gaat er voordat deze aflevering is, gaat die eruit. Of in ieder geval als die beschikbaar is, dan kun je in ieder geval subscribe. Dat is het. Meer heb ik niet te melden. Ik wil jou nogmaals bedanken, Jeroen. Graag gedaan. En het was top. We gaan trouwens ook jouw podcast. Je hebt een podcast die je in de show notes zet. Mocht je nog meet-ups hebben of zoiets dergelijks. Die de komende tijd relevant zijn. Ja, ik zal ze zeker even melden in de Slack. Ja, in de Slack is dat sowieso handig. Podcast kun je gewoon vinden in je player en zoeken op AppForce One. Eén aan het einde. En dan vind je hem wel. Het getal één. Cool. Nou, dat was het dan. Tot de volgende keer. Maar dan weer het luisteren. Doei, doei. Doei, doei.