Entwarnung mit Mehraufwand
Verbot von Baukasten-Apps: Apple macht Zugeständnisse
Nach anhaltender Kritik hat Apple jetzt seine Entwickler-Richtlinien überarbeitet und das angekündigte Verbot von Baukasten-Applikationen zum Januar 2018 etwas aufgeweicht.
Wie der Konzern nun mitteilt sollen zukünftig doch nicht alle iPhone-Anwendungen abgelehnt werden, die auf vorgefertigte Schablonen setzen und diese lediglich mit leicht variierenden Inhalten ausstatten, sondern nur noch jene, die nicht vom Anbieter des angebotenen Inhaltes in den App Store eingereicht werden.
Anders formuliert: Wenn das Entwickler-Studio XYZ eine Restaurant-App für Gastro-Betriebe zur Tischreservierung anbietet, dann dürfen die Restaurants A, B und C fortan nur noch die gleiche App (mit den jeweils individuellen Reservierungs-Funkionen) nutzen, wenn diese nicht vom Entwickler-Studio XYZ sondern von den Restaurants selbst in den App Store eingereicht wurde.
Einerseits dürfte die Änderung der Richtlinien die besorgten Kritiker aus Reihen des Mittelstand zwar etwas beruhigen, andererseits geht die Neuformulierung auch mit einem erheblich größeren Arbeitsaufwand einher, da Entwickler die Apps ihrer Kunden fortan nicht mehr gesammelt verwalten dürfen, sondern für jeden Kunden einen eigenen iTunes Connect-Account pflegen müssen.
Während Apple in Punkt 4.2.6 seine Entwickler-Richtlinien bislang lediglich konstatierte:
Apps created from a commercialized template or app generation service will be rejected.
Hat Cupertino die Passage nun ausführlicher formuliert und erklärt:
Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.