Wat bouw ik precies?
Ik werk op de Apple-platformen: iPhone, iPad, Mac en Apple Watch. Ontwerp en bouw liggen bij dezelfde persoon. Ik teken een scherm niet af om het daarna weg te geven, ik bouw het en pas het aan zodra blijkt dat het in de hand anders werkt dan op het scherm.
Ik richt me op vier soorten werk:
- Een nieuwe app vanaf niets. Van het eerste ontwerp tot een versie die de App Store in kan.
- Een bestaande app uitbreiden. Nieuwe schermen, een Mac- of Apple Watch-versie naast de iPhone-app, of een deel dat opnieuw moet.
- De onderdelen die blijven liggen. Synchronisatie via CloudKit, abonnementen en aankopen via StoreKit, widgets en Live Activities, versleutelde opslag, een systeemtoetsenbord, of een sneltoets die overal in het systeem werkt.
- Tijdelijk de Apple-kennis in een team dat wel een web- en serverkant heeft, maar niemand die de iOS-kant kan dragen.
Waarom native, en wanneer je beter iets anders kiest
Native is bij mij geen principe maar een keuze met een reden. Een app die vooral inhoud toont en formulieren invult, en verder weinig van het toestel vraagt, bouw je prima in Flutter of React Native. Zit je team al vol webontwikkelaars, dan is dat de goedkopere weg.
Het verschil wordt zichtbaar zodra de app het systeem in moet: een toetsenbordextensie, een sneltoets die buiten je app om werkt, widgets en Live Activities, een horloge-app, audio die doorloopt op de achtergrond, verwerking op het toestel zelf. Daar wordt cross-platform brokkelig. Je komt alsnog in Swift uit, maar via een brug, met een laag ertussen die je niet kunt debuggen als het misgaat. Nieuwe systeemfuncties zijn er bovendien op de dag van de OS-release, terwijl een raamwerk van derden er eerst een versie voor moet uitbrengen.
Daarnaast is er het deel dat niet in een vergelijkingstabel past: hoe een app aanvoelt. Ik bouw apps die op het platform thuishoren. Snel, stil, met het systeem meegebouwd in plaats van ertegenin.
Dit staat er ook om je een mail te besparen. Zoek je iemand voor Flutter of React Native, dan ben ik het niet.
Welke techniek gebruik ik?
Dit is de lijst waar ik werk bij kan laten zien, niet de lijst die goed staat:
- Apple: Swift, SwiftUI, SwiftData, CloudKit, StoreKit, WidgetKit en Live Activities, watchOS en macOS.
- Server: .NET, PostgreSQL, Docker, Kubernetes, en uitrollen via GitHub Actions.
- Web: Astro voor sites, Vite en three.js voor 3D in de browser.
Die tweede regel noem ik apart, want een app is bijna nooit alleen een app. Er hoort een API bij, een database, een plek waar dat draait en een manier om het uit te rollen. Ligt dat stuk bij een andere partij, dan staat jouw iOS-planning stil zodra hun planning stilstaat. Ik kan die kant zelf bouwen en draaiend houden, of meedenken met de mensen die het al doen.
Hoe loopt een opdracht?
Een opdracht begint met een gesprek waarin ik vooral vraag: wat moet de app doen, voor wie, wat ligt er al, wie hakt de knopen door, en waar zit de druk. Daarna schrijf ik op een half A4 op wat ik denk te gaan doen en wat ik nog niet weet. Dat stuk is bedoeld om het oneens over te zijn voordat er code ligt.
Tijdens de opdracht werk ik in jouw repository, jouw branches en jouw reviewproces. Is er nog niets, dan zet ik dat op, inclusief een pijplijn die bij elke wijziging bouwt, zodat "bij mij doet het het wel" geen argument meer is.
Ik lever in werkende builds die je zelf op een toestel zet, niet in schermafbeeldingen of een demo op mijn scherm. Iets dat je een dag zelf gebruikt, beoordeel je anders dan iets dat iemand je voordoet.
Verder houd ik me aan een paar afspraken die zelden opgeschreven worden:
- Keuzes met gevolgen, zoals architectuur, datamodel of een afhankelijkheid van buiten, schrijf ik op met de reden erbij. Wie na mij komt moet kunnen zien waarom iets zo staat.
- Schattingen geef ik per onderdeel, niet als één getal voor een hele app. Loopt iets uit, dan hoor je dat terwijl het gebeurt en niet aan het eind.
- Overleg gaat schriftelijk waar het kan en in gesprek waar het moet. Staat je team dagelijks bij elkaar, dan sluit ik aan.
Wat komt er kijken bij opleveren in de App Store?
De laatste tien procent van een app-project zit zelden in de app. Het zit in de keten eromheen, en die wordt bij het plannen bijna altijd overgeslagen:
- Certificaten, profielen en ondertekening, plus de capabilities in het ontwikkelaarsportaal: iCloud, pushberichten, gedeelde app-groepen, inloggen met Apple. Elke capability die pas achteraf nodig blijkt, kost een nieuwe build.
- Aankopen en abonnementen: producten aanmaken in App Store Connect, koppelen aan de StoreKit-code, en het geheel in een sandbox testen voordat er echt geld doorheen loopt.
- De privacy-opgave: per soort gegeven verklaren wat je verzamelt en waarvoor. Dat is geen formaliteit, want wat je aanvinkt moet kloppen met wat de code doet.
- Schermafbeeldingen per formaat, teksten, leeftijdsclassificatie, en een ronde met testers op echte toestellen via TestFlight.
Ik reken dit tot de opdracht. Wat ik niet doe, is een datum beloven voor de beoordeling zelf, want dat deel ligt bij Apple.
Welke opdrachten passen, en welke niet?
Wat past
- Een app die op het systeem moet leunen: een toetsenbord dat overal werkt, een sneltoets buiten de app om, widgets, een horloge-versie, audio op de achtergrond, verwerking op het toestel.
- Een idee dat van niets naar een indienbare app moet, waarbij iemand ook keuzes maakt in plaats van alleen tekeningen uitvoert.
- Een bestaande Apple-app met achterstand: een nieuw OS dat dingen breekt, schermen die vastzitten, synchronisatie die stilletjes niet werkt.
- Een productteam dat sterk is op web en server, maar geen Apple-kennis in huis heeft.
Wat niet past
- Flutter, React Native, Ionic, of een website in een appschil.
- Android. Naast een Android-collega werken gaat prima, die kant zelf bouwen doe ik niet.
- Werk waarbij ik alleen tickets krijg en nooit hoor waarom iets gebouwd wordt. Iemand die daar wel goed in gedijt levert je meer op dan ik.
- Een vastgezette einddatum voor werk waarvan de omvang nog open ligt. Dan kiezen we vooraf wat vaststaat, de datum of de omvang, in plaats van dat halverwege te ontdekken.
Waarop kun je dit controleren?
Er staan hier geen klantlogo's en geen aanbevelingen die je toch niet kunt nagaan. Wat er wel is, is werk dat je zelf kunt bekijken.
Transcribier is spraakdictaat voor Mac, iPhone en iPad. Je spreekt, het typt, in elk tekstveld. Daar zit vrijwel alles in wat een Apple-app lastig maakt: een systeemtoetsenbord op iOS, een globale sneltoets op de Mac, een abonnement via StoreKit, synchronisatie via het iCloud-account van de gebruiker, sleutels in de Keychain en een slot met Face ID. Het transcriberen loopt via ElevenLabs Scribe in zestien talen, met de sleutel van de gebruiker zelf, zodat audio niet langs mijn servers gaat.
Best-I, een app om je energiebalans bij te houden is Nederlandstalig en laat zien waar je energie blijft, met een versleuteld dagboek eromheen voor tekst, foto's, video, spraakmemo's en tekeningen. De opslag is versleuteld met AES-256-GCM, de sleutels worden op het toestel aangemaakt en in de keychain bewaard, zoeken gebeurt volledig op het toestel, en er zit geen advertentie- of analytics-SDK van derden in.
Eén ding hoort daar meteen bij: geen van beide apps staat op dit moment in de App Store. Voor Transcribier is er een wachtlijst, Best-I komt binnenkort uit. Je beoordeelt dus het werk zelf en niet een positie in een ranglijst.
Deze site is ook werk. Het is geen thema maar een 3D-ervaring in de browser, gebouwd met Vite en three.js. Heb je eerder een idee dan een vacature, kijk dan bij app laten maken.