Als het ogenschijnlijk goedkoper kan, waarom zou je dan niet een framework app laten maken? Het antwoord op deze vraag is eigenlijk heel eenvoudig. De eerder genoemde frameworks zijn altijd een "black box", zoals app ontwikkelaars dat noemen. Je schrijft de code in de taal van het framework en vervolgens wordt er een vertaalslag gemaakt.
Je weet als app developer dan ook niet zo goed wat er mis gaat áls het resultaat niet is wat je er van had verwacht – omdat er dus niet transparante vertalingen worden gedaan. Dat kan veel tijd kosten aan research, testing en vervolgens nieuwe uren aan app development. Daarnaast zijn dergelijke frameworks vaak overgeleverd aan de grillen van de maker (meestal start-ups uit Silicon Valley, soms zelfs zonder enige vorm van financiering) en worden ook nog wel eens massaal gedumpt of aan hun spreekwoordelijke lot over gelaten.
Anekdotes
Een voorbeeld:
Xamarin bood bijvoorbeeld een aantal jaar geleden geen ondersteuning voor 64-bit apps en duurde het maanden voor ze deze ondersteuning wél boden, in de tussentijd konden er geen nieuwe iOS apps ingestuurd worden.
Een ander voorbeeld:
SpriteBuilder (een framework om eenvoudig en snel animaties te kunnen ontwikkelen voor Cocos2D games), de medewerkers liepen weg omdat het bedrijf geen financiële middelen meer had. Gevolg is dat de founder gedwongen werd om een andere baan te zoeken en in zijn vrije tijd het framework verder te ontwikkelen en te ondersteunen. Dit leverde veel problemen op met onreleasebare apps tot gevolg.
Hoewel we er toe in staat zijn dergelijke frameworks zonder problemen in te zetten en uit te breiden, zijn we er door onze ervaringen veel voorzichtiger mee geworden. De enige manier waarop we een framework app verkopen is als we zeker weten dat dergelijke scenario's niet kunnen optreden en we een degelijke software oplossingen verkopen.
De stelregel is voor ons wel geworden: hoe belangrijker de app voor de (kerntaken van de) organisatie, hoe meer redenen om de app native te ontwikkelen.
