'Apple gaat strenger optreden tegen ontwikkelaars die apps via templates bouwen'

Apple lijkt van plan te zijn om zijn verbod op het gebruik van templates om applicaties te bouwen strenger na te leven. Verscheidene bedrijven zijn gewaarschuwd dat hun applicaties vanaf volgend jaar niet langer door de controle komen.

Dat meldt TechCrunch op basis van ervaringen van verscheidene bedrijven, die zijn aangeschreven door Apple. In de genoemde correspondentie laat Apple weten aan ontwikkelaars dat zij tot 1 januari de tijd krijgen om hun applicaties aan te passen. Daarna zullen nieuwe versies bij indiening niet door de controle komen, en dus waarschijnlijk worden verwijderd uit de App Store. Het gaat dan om applicaties die gebruik maken van een commercieel verkrijgbare template voor het bouwen van apps, of applicaties die gebouwd zijn met een zogenaamde appgenerator.

Alhoewel Apple al regels had die het gebruik van dergelijke tools voor het bouwen van applicaties tegen moeten gaan, werd hier voorheen niet zo streng op gelet. Het bedrijf uit Cupertino lijkt dus het voornemen te hebben om hier vanaf volgend jaar strenger op te treden en sneller applicaties uit de App Store te verwijderen.

TechCrunch stelt dat de strengere regels mogelijk gevolgen hebben voor kleine bedrijven, die mogelijk niet de capaciteiten hebben om volledig zelfstandig een applicatie te ontwikkelen, of om een bedrijf in te huren om de software te laten bouwen. Zo sprak de techsite onder meer met Shoutem, dat enkele weken geleden de deuren sloot omdat het door de regels van Apple niet langer zijn software kon aanbieden.

Apple staat het gebruik van templates en appgenerators niet toe om de kwaliteit van de applicaties hoog te houden. Apps die op dergelijke wijze zijn gebouwd zijn vaker van lage kwaliteit dan software die volledig zelfstandig is gebouwd.

Reacties (202)

[ExIT]

Browser template app + html5 site is vaak voldoende voor kleine bedrijven. Daar kan zelfs een template onder 1 developer in de appstore geen technisch kwaliteitsverlies van ondervinden.

Wat Apple in 2018 lijkt te willen is dat elke Jan Doedel zelf registreert als developer (papierwinkel, voorwaarden, etc) en daarmee méér inkomsten oplevert. Maar ook dan worden templates gebruikt. En dan is het vast geen euvel meer, net als dat het geen prio had in de jaren hiervoor.

[supersnathan94]

Als die HTML 5 site goed werkt waarom bouwen ze er dan een template browser app omheen? Hierdoor moeten ze juist die hele papierwinkel door terwijl ze ook gewoon een homescreen bookmark kunnen laten toevoegen met dezelfde functionaliteit maar dan vele malen goedkoper.

Als geld een issue is dan moet je het daar maar mee doen toch?

[Gamebuster]

Wij hebben gewoon volledige client-side offline-first responsive javascript apps wrapped in UIWebView in de appstore staan. De javascript client is identiek aan de versie die we deployen voor de browser: We builden een HTML, JS en CSS file, gooien deze in de app bundle samen met een paar regels Swift en dat is het wel zo ongeveer. Voor sommige apps hebben we subtiele integratie met native features, zoals het gebruik van de camera om barcodes te scannen. Hierbij implementeren we de barcode-scanner in de native app en registeren we Javascript-bindings ervoor. De javascript client kijkt voor de aanwezigheid van deze bindings, en toont de relevante interfaces wanneer de bindings aanwezig zijn (in de apps dus, en niet in een browser).

We hebben nog nooit problemen gehad om deze apps in de app-store te krijgen. Voorwaarde lijkt wel te zijn dat je de benodigde javascript/html/css in je app zet en niet gewoon een URL opent.

Qua interface zijn ze niet geweldig - een kenner ziet dat het geen echte native app is. We gebruiken bootstrap CSS met wat aanpassingen zodat het wat meer "iOS-achtig" lijkt. We gebruiken geen animaties e.d. Het zijn vooral "quick & dirty" zakelijke apps, maar ze werken eigenlijk best degelijk. Gebruikers zijn over het algemeen ook tevreden ermee

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[MenN]

Juist voor dat soort apps komen er steeds betere web technieken, waardoor het hebben van een native app niet meer nodig is. Dit soort zakelijke apps kun je prima als Progressive WebApp opzetten, dan kan je die gelijk op elk platform gebruiken en heb je de voordelen van native en web gecombineerd.

[martijnsch]

"Ja maar wij willen vindbaar zijn in de App Store en dat mensen een Icoontje op hun beginscherm hebben. Wat? Toevoegen aan beginscherm via een menu in Safari? Dat klinkt te ingewikkeld.."

[kozue]

Oftewel het wordt tijd dat Apple ondersteuning toevoegt voor webapps in de app store. Waarbij zo'n webapp uiteraard geen gare webview wrapper-app installeert, maar gewoon een shortcut naar de mobiele website op je homescreen zet, net alsof het een app was. Geen hond die het verschil zou merken, en scheelt een hoop geupdate.

Misschien kunnen we dan eindelijk eens af van al die slechte wrappers rondom een html5 website die plek op het apparaat innemen, en misschien langzaam eens wegbewegen van die vervelende hype van websites die je naar de app doorverwijzen (als ik een app wilde zat ik niet op je site ok?).

[erikieperikie]

Dit. En dit weet en wil Apple ook wel, maar pas zodra zij er echt niet meer aan kunnen verdienen, wat ze nu doen door het laatste beetje sap te persen uit hun ontwikkelaars en gebruikers van templates. Apple is qua software matig vooruitstrevend en dit is zo'n ding waar je als Windows / Linux / Android over een paar jaar zegt: hebben wij al jaren, terwijl Apple er dan een grote gehypete Keynote van maakt en presenteert: webapplicaties zijn voor de gebruiker niet meer te onderscheiden van native apps!

[Gamebuster]

Ja dat is te ingewikkeld en mensen doen dat niet. En gebruikers/klanten/investeerders/whatevers willen apps... als je zegt "ja euh je kan..." wordt je onderbroken met de vraag "heb je nou een app of niet?" en ik heb opgegeven het uit te leggen en gewoon een app te deployen met onze web-app erin.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[supersnathan94]

Een web-app is toch net zo goed een app? Als ik zelf een app bouw, deze niet in de store zet en hem zelf sideload heb ik toch ook een app? Dat iets niet in de store staat betekent niet dat het geen app is. Als management zo loopt te doen is het tijd voor een nieuw project.

[Gamebuster]

Ik ben management, en het zijn de gebruikers en klanten die het willen. En zij betalen uiteindelijk de rekening. Geloof me, heb de discussie 10x gevoerd met collega’s, klanten, investeerders en gebruikers om het met sideloaden te proberen. Dat side-loaden doen mensen gewoon niet en zo loop je gebruikers mis

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[JannyWooWoo]

Maar Apple wil het dus niet meer, en als eigenaar van de Appstore winnen ze dit argument.

Sideloaden is idd geen optie maar als de App voor intern gebruik is dan is het gewoon echt tijd om een MDM platform aan te schaffen. Voor extern zal idd de gebruiker moeten wennen aan web apps en hoe die op hun home screen te zetten.

[supersnathan94]

^ dit.

Met MDM kan je namelijk gewoon direct een nieuwe versie pushen zonder gezeur. Je klant kan dit ook niet zomaar even overrulen en zit daarmee dus ook altijd op de laatste versie.

Daarmee is MDM al gratis verkrijgbaar met Configurator 2 en kan je daarmee al je iPhones en iPads beheren.

[Verwijderd]

Zelfs al willen "wij" dat niet, de eindgebruiker verwacht het vaak. Wij hebben geen apps in de AppStore omdat de browser (en een aantal 3rd-party apps) prima gebruikt kan worden. Gevolg: e-mails dat mensen onze app niet kunnen vinden.

Het is niet zo dat er duizenden e-mails per dag over binnenkomen, maar ze komen wel, en kosten ook tijd en geld, zowel voor ons support team als die eindgebruiker. Een app die eigenlijk gewoon een website opent is dan een goedkope "oplossing".

Wij hebben het uiteindelijk niet gedaan, maar de reden om het te doen begrijp ik erg goed.

[Gamebuster]

Web Assembly Dan kunnen we onze apps maken in $JOUW_FAVORIETE_TAAL en deployen naar ieder platform. Weg met javascript! Gebrek aan immutable/data types en een lading rare eigenschappen maakt het gewoon een bron van bugs in grote applicaties

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[Woutske]

Nee, dat kan niet. Ik zou het graag zo zien maar voorlopig heeft Safari op IOS nog geen enkele support voor service workers of toegang tot device features.

Wij hebben evengoed een PWA omdat we verwachten dat het er aan zit te komen. Maar de PWA in Cordova wrappen blijft op iOS helaas wel nodig nu.

[loopezz]

Dan zou ik eens kijken naar Ionic Framework. Ik kan het gebruik ervan ten zeerste aanraden.

[Gamebuster]

Het ziet er best oke uit, maar dat het geld kost en dingen als "60 day error history" vind ik erg eng, zeker nu blijkt dat ik me nu ook al prima red met Vue + Bootstrap + beetje stylen

[loopezz]

Het is gratis en je kunt het ook in jouw eigen Git zetten. Er zitten dus geen nadelen aan wat dat betreft. Natuurlijk zijn er betaalde opties die afgenomen kunnen worden, maar daar is geen noodzaak voor. Integendeel, je hebt niet eens een account nodig om met Ionic te kunnen starten en apps uit te brengen. Op een developer account na dan voor Android en iOS.

Ik zou eens de documentatie doornemen, met name het hoofdstuk "Components", "API" en "Native".

Wij hebben overigens (nog) geen meldig ontvangen van Apple over bepaalde richtlijnen. Ik vermoed ook niet dat Ionic onder templated apps valt. Je kunt apps geheel custom maken zoals jezelf wilt. Untappd is ook met Ionic gemaakt.

[biglia]

Dat gebruik ik ook samen met Phonegap/Cordova. Mijn App werd direct goedgekeurd door Apple. Het voordeel is ook dat het zonder veel aanpassingen werkt voor Android. Enkel de AngularJs was een steile leercurve.

Zouden deze oplossingen ook vallen onder de strengere eisen?

[Reactie gewijzigd door biglia op 23 juli 2024 02:13]

[supersnathan94]

Nee ionic valt hier buiten. Is geen sleur en pleur met standaard componenten, maar custom software die je zelf bouwt.

[Knijpoog]

"Wij hebben gewoon volledige client-side offline-first responsive javascript apps wrapped in UIWebView in de appstore staan."

Ik denk dat een hoop mensen lezen: "Wij hebben gewoon volledige ??? in de appstore staan.

[Sijtzeb]

Wat is je doel van je comment?..

client-side = alles draait op de device van de gebruiker
offline-first = manier van ontwikkelen met nadruk op offline gebruik
responsive = schaalbaarheid tussen verschillende devices(mobile/desk etc) en nee, dit doe je niet met één knopje
javascript = taaltje
wrapped = gewoon een Engels woord
UIWebView = in apps kan je gebruik maken van een WebView dat simpel weg html in laad en oogt als een normale view van de app zelf

Serieus, deze termen zijn super basaal, niet eigen tot ontwikkelaars en zou elke leek op tweakers wel enigszins moeten snappen.

[Sietse Vliegen]

Ook in de manuals van de spaceshuttle staan heel gewone begrippen. Daarmee begrijp je als burger nog niet wat NASA bedoelt

[RebelwaClue]

Ik dacht dat er iets in klingon stond

[TheMak]

Werkt het in combinatie met VoiceOver?

[Gamebuster]

Geen idee, ik ga ervan uit dat het niet werkt. Nog nooit een gebruiker horen klagen erover. Misschien kunnen ze geen contactgegevens vinden omdat VoiceOver niet werkt

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[Emiel L]

Dit is echt zo super slecht. Jij bent helaas lang niet de enige die er een lolletje van maakt. Ga voor de grap eens kijken op een dag waar mensen die afhankelijk zijn van dit soort technieken aanwezig zijn. Hopelijk draai je dan wat bij en zie je het belang hiervan. Het frustreert mij enorm dat de werkgevers waar ik tot nog toe voor heb gewerkt ook apps maken voor dingen als verzekeringen en als je het onderwerp accessibility bij de teams en de klant naar voren brengt kijken ze me aan alsof ik iets heel raars voorstel. "Oh, nooit zo,over gedacht. Is vast heel duur, dus dat doen we niet"...

[Gamebuster]

Tja euh we maken vooral business to business apps. Geen idee in welk scenario Voiceover support dan relevant is. Ik zie een blinde geen barcodes scannen, foto’s van documenten maken, gegevens overtypen, gescande data controleren of slachtvee vervoeren. De helft staat niet eens in de appstore.

Wat we maken zijn meestal quick & dirty prototypes, experimentjes met bestaande markten, om daarna verder ontwikkeld te worden (lees: in de prullenbak en daarna goed) of weggegooid te worden. In een paar weken (soms zelfs in 2 weken) een crappy oplossing die bruikbaar is voor een zacht prijsje. Dat zijn keuzes die bewust gemaakt worden en waarom gevraagd wordt, niet omdat we geen fatsoenlijke dingen kunnen maken. Soms worden die dingen langdurig in productie gebruikt... tja dat was tegen ons advies in

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[FvdM]

Ik zie een blinde geen barcodes scannen, foto’s van documenten maken, gegevens overtypen, gescande data controleren of slachtvee vervoeren. De helft staat niet eens in de appstore.

Waarom niet? Als de tools en werkgever een beetje serieus zijn kan ook een blinde visuele handelingen verrichten.

Bijvoorbeeld een document in een duplex scanner leggen, instellen en uitvoeren kan prima zonder zicht. Middels voelbare buttons of voice commands en geluiden. De meeste software van nu doet de rest, zoals pagina omdraaien en lege pagina's verwijderen. Zelfs mijn all in one thuis kan dat.

[Gamebuster]

blablabla je hebt mijn bericht niet eens gelezen geloof ik

[FvdM]

Vreemde reactie, ik ben gewoon benieuwd waarom je denkt dat een blinde die dingen niet kan doen.

[Blackouts]

Ik heb nog nooit zoveel Engelse woorden in een stuk Nederlandse tekst gelezen....

[Gamebuster]

Of Nederlandse woorden in Engels ... hmmmm

[DohnJoe]

Voor veel mensen is gewoon een bookmark toevoegen op homescreen helaas al teveel gevraagd, een app laten installeren lukt ze vaak wel.

Daarnaast staat een app ook beter.

[xFeverr]

Een bookmark toevoegen is alles behalve moeilijk, met een app installeren ben je langer bezig. Bovendien staat een app echt niet beter... Een native app, dat staat beter. Weg met die webapplicaties in de store. Als het toch niks meer kan dan een webapp in de standaard browser, hoeft het daar ook niet te staan.

[DohnJoe]

Een app kan je via een link naar de app store laten installeren, is er iets vergelijkbaar eenvoudigs om mensen automatisch een link op hun homescreen te laten toevoegen? Ik hoor het graag...

Ik ben met je eens dat een native app nog beter staat, het punt was echter dat een browser app beter staat dan een bookmark.

[jip_86]

Ja hoor, kan niet voor de andere browsers spreken maar Chrome in ieder geval wel: https://developers.google...tals/app-install-banners/

[HyperVize]

Precies dit. Mooi zou zijn als Tweakers dit ook implementeert. Ik gebruik nu ook Tweakers via mijn homescreen en voelt als een native app.

[Gamebuster]

Heb je dit ook voor iOS? Met die popup?

[supersnathan94]

Niet exact hetzelfde, maar wel een eenvoudige manier om de gebruiker stapsgewijs erdoor te slepen: http://cubiq.org/add-to-home-screen

gelukkig kan het niet door programmaturele kunstjes. als dev is het leuk, maar als gebruiker wordt het snel een irritatie door pop-ups die het ook doen bijvoorbeeld. krijg je van die irritante casino apps enzo.

[AndromedaM31]

Ik heb al zo veel bookmarks, dan pin je een site vast op je homescreen en waneer je daar op klikt: hup browser open met de desbetreffende bookmark. ben ik weer helemaal uit de browser flow en moet ik weer 10tallen tabs teruggaan naar de oorspronkelijke tab.

Ja, dat schiet lekker op als je veel websites als app/bookmark hebt.

Hoe moeilijk kan het zijn om hiervoor een oplossing voor te bedenken? Dan moeten er afgeschermde browser vensters komen die in hun eigen bookmark schil draaien los van de browser venster.

Ik gebruik Android. Ben heel benieuwd hoe dit nu op iOS is.

[N8w8]

Hier is een mooie oplossing voor Android, alleen moeten sitebouwers dat dan wel implementeren.

[jochem4207]

Het gaat niet omdat het moeilijk is maar om wat een gemiddelde niet technische gebruiker wel en niet snel doet.

[ikweethetbeter]

Voor veel mensen is gewoon een bookmark toevoegen op homescreen helaas al teveel gevraagd, een app laten installeren lukt ze vaak wel.

Een app van weer 50MB, die de functionaliteit van een bookmark heeft? Doe mij dan aub een bookmark, en niet weer zo'n nutteloze app. Daarvoor hebben ze browsers uitgevonden!

[Blokker_1999]

Omdat je op deze manier in de app store komt en daar weer gevonden kunt worden. Je kan dan zeggen: we hebben een app.

[AndromedaM31]

Apple kan ook een mooie omgeving maken voor web apps. Zoveel mogelijkheden.

[Reactie gewijzigd door AndromedaM31 op 23 juli 2024 02:13]

[pBook]

Zo zijn ze ooit begonnen, voordat de App Store kwam met iPhone OS 2.0. Was geen daverend success.

[Gamebuster]

Javascript/HTML/CSS was gewoon nog niet klaar ervoor. Nu nog steeds niet, overigens...

[supersnathan94]

Het is wel grappig dat ik je in meerdere posts hoor klagen over het gedrocht dat HTMLcssJscript heet en dat je toch weet vol te houden dat een wrapper schil daaromheen de oplossing is. Javascript applicaties draaien tegenwoordig onwijs veel in productie omgevingen bij grote bedrijven als bol.com en coolblue.

[Gamebuster]

HTML, CSS en Javascript zijn een gedrocht en zijn ongeschikt voor het maken van moderne cloud-applicaties. Daartegen is het wel de enige manier om voor ieder platform een app te krijgen, inclusief de browser.* (*ja er zijn vast uitzonderingen die uiteindelijk allemaal compilen naar Javascript zolang WASM er nog niet is)

Het "het draait tegenwoordig in onwijs veel productie omgevingen" argument vind ik complete bullshit. Natuurlijk draaien er grote HTML, CSS en Javascript applicaties in productie omgevingen van websites... duh! Dat maakt de techniek niet per se beter.

Mijn primaire probleem ligt bij Javascript, overigens. In de jaren 60 wisten een hele hoop knappe koppen dat shared mutable state evil is, en Javascript is een taal die waarbij alles standaard shared-mutable-state is, tenzij je actief eromheen werkt. De standard library van Javascript is zo fucking idioot slecht dat de beste manier om String.repeat te implementeren is door een Array aan te maken met een bepaalde lengte en die te joinen met je gewenste string. Verder... dat de 1e maand van het jaar 0 is, en dat er zo goed als geen datetime manipulatie is behalve de standaard Date-object, dat altijd gepaard gaat met een tijdzone. Concepten als "wall-time", tijdsduur, calenders en dat soort ongein heb je niet. Gelukkig kan je 200kb aan Javascript meuk inladen als je simpele datum-manipulatie wil doen, met allemaal DSLetjes waar niemand overeenstemming in kan vinden, net als in alle andere 1000 libraries. Oh, en hoe wil je je library installeren? Prima! Heb je Npm, gulp, brunch, grunt, browserify, rollup, sprockets, fly, gobble, webpack, CDN, download minified, download dev versie, een custom build, of 1 van al deze anderen? ( https://babeljs.io/docs/setup )

Als jij met tegenargument gaat komen om mij te overtuigen hoe geweldig javascript is, moet je even stilstaan bij het feit dat er ontelbaar hoeveelheid Javascript & dialecten varianten zijn: ES5, ES6, ESNEXT, Typescript, coffeescript, fuckmescript, fuckdatscript, en nog eens 100 taaltjes die naar Javascript compilen. De rede dat al die idiote kut talen bestaan is omdat Javascript een blok aan ieders been is waar niemand vanaf komt, dus ga je het maar proberen te verstoppen in een likje verf met 100 plugins en transpilers, met daarbij een hele collectie aan gigantische build tools.

Dan CSS. Tja euh... in C had je nog meer encapsulation & modulary dan in CSS. Oh, je laadt een externe widget in? Oh kut, 1 van mijn jQuery libraries komt met een CSS file waarin er globaal een .active style wordt gezet, en nu zijn random allemaal menu-items stuk die styles uit een andere module hebben met de naam .active. Alles is global by default. Jeej! Geen namespaces of modules, gewoon hup alles global. Als soort-van oplossing heb je nested selectors, maar die moet je dan iedere keer weer typen (tenzij je SASS/LESS/SCSS gebruikt) en zelfs dan heb je nog steeds kans dat styles in de ene "namespace" lekt naar zijn children. Stel je voor, je hebt een .tab namespace met een .active class, met daarin een .link-item met een .active class. De style definities van .tab .active staan in file A en voor .link-item .active staan in file B. Je denkt dat ze gescheiden blijven, maar zodra je een tab in een link-item, of een link-item in een tab zet, delen ze alsnog de styles van elkaar's .active. Zucht. Dan maar weer alles heel verbose typen zoals BEM.

En die build tool die je gebruikt om je 100 stylesheets aan elkaar te plakken uit 20 frameworks, plugins en andere zooi heeft een update gehad, waardoor de volgorde aan styles nu net iets anders is waardoor bepaalde styles opeens wel prioriteit krijgen over anderen en dingen random anders eruit zien. Oeps!

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[matty___]

Grotendeels eens maar toch erg aangedikt. Dat er 100 dialecten zijn boeit niet. ES6 en Typescript hebben de toekomst.

Over CSS gesproken. Op het moment dat je fatsoenlijke componenten hebt of zoals Angular het doet lekt er niets.
Ik proef vooral frustraties over hoe je jaren geleden iets bouwde maar het is een kwestie van de juiste tech keuzes maken (voor nu dan ) Dat het allemaal vaak veranderd kan ik echter ook niet ontkennen. Maar pas in de laatste paar jaar zijn er echte meters gemaakt op dat gebied met helaas veel legacy.

Maar goed wat is jouw oplossing dan voor dynamische webapps in de browser?

[Gamebuster]

Mijn oplossing is de browser steeds dommer maken, alleen een low level interface voor browser interacties bieden met een bytecode interpreter.

Dit kan je niet even omgooien natuurlijk, maar WebAssembly is wel een forse stap naar de toekomst.

Het idee is dat je dan ook native apps direct naar de browser kan compilen, al mis je dan natuurlijk wel je OS GUI frameworks.

Je cloud app maak je dan in jouw favoriete taal (C C# Swift Java Kotlin Ruby - whatever), compile je naar bytecode, en dat deploy je.

Specifieke URLs geven configuratie files terug met referenties naar alle benodigde modules. Nieuw HTTP protocol kan deze modules al meteen meegeven voordat erom gevraagd wordt.

[valvy]

Es5 is letterlijk gewoon javascript, es6 is de volgende versie en die daarna is idd next. Dat zonder compilatie werkt in de browser. Om dan te zeggen dat er ontelbaar versies zijn zou je java ook vervelend moeten vinden omdat er java 7/8/9 is met talen zoals scala en clojure eromheen.

Ook jou vergelijking met het ecosysteem is een beetje scheef, de taal staat los van het ecosysteem. Ik ga ook geen java bashen vanwege gradle/maven of c++ bashen voor CMake en visual studio? Die bibliotheken die je opnoemde zijn er om het leven makkelijker te maken, doen ze dat niet dan negeer je ze toch gewoon?

[pBook]

ES5/ES6 heeft niet zoveel te maken met Typescript/Coffeescript en er voor het builden van JS/CSS zijn zat complete en goede oplossingen te vinden. Je moet hier inderdaad tijd in steken maar dit soort shit moet je gewoon op orde hebben voordat je aan je app begint te bouwen. Als de ene .active de andere in de weg zit, weet je gewoon niet hoe je een grote bedrijfsapps moet bouwen voor het web. Voor de meeste bedrijven zijn web apps een godsgeschenk omdat je niet gelockt zit aan één OS of platform. Er zijn zat web apps die voor de eindgebruiker prettiger werken dan native apps, dat heeft denk ik meer met de kunde van de interface designer te maken dan met de techniek.

Ik zeg niet dat Javascript geweldig is en heb ook geen reden om je te overtuigen, je setup gereedmaken voor native apps is misschien wel minder werk en geeft misschien beter resultaat, maar je kan hele mooie dingen bouwen met CSS en JS als je weet wat je aan het doen bent.

[Reactie gewijzigd door pBook op 23 juli 2024 02:13]

[Gamebuster]

Ik weet het ja - Het is mijn fulltime baan om mooi dingen te maken met CSS/JS. Ik weet ook wel ongeveer wat ik doe na het heel veel fout gedaan te hebben. Ik werk nu vooral met Vue single file components, volledig test-driven. Daarnaast losse javascript classes voor domeinlogica. En vooral heel veel tests... unit tests, integratie tests, end to end tests... ik heb volgens mij meer regels tests dan code. Zonder tests zou ik echt niet rustig slapen...

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[supersnathan94]

En toh blijft iedereen het gebruiken om dat men te lui is om verschillende apps te bouwen.

Kijk ik snap je punt wel, maar de oplossing is dan dus gewon native apps maken die dit gezeik niet hebben. Dus daadwerkelijk iOS en android apps maken. Gewoon zoals Apple nu ook aangeeft omdat het anders gewoon eigenlijk ook ruk is.

Neemt overigens niet weg dat iedere taal eigenlijk een een transpiling berg is van hier tot ginter. Hell Java heeft zelfs een virtuele machine war de spulleboel in draait. (Ja typo in purpose ).

Punt is meer dat de oplossing al bestaat met alle voor en nadelen van dien, maar dat kennelijk te veel werk is ofzo?

[Tielenaar]

Haha, mooi stukje
Daarom mag er ook wel wat meer respect komen voor frontenders die dit allemaal onder de knie weten te krijgen!
Er zit veel waarheid in je verhaal, in de meeste gevallen kan je met wat extra werk prima overweg met al die ellende. Door ervaring kom je een heel eind. Desalniettemin is html/js/css tot nu toe de enige manier om een applicatie voor elk platform toegankelijk te maken zonder alles dubbel te maken.
Wat mij betreft gaat het lekker zo door en worden 90% van de app/playstore apps gewoon websites.

[Maurits van Baerle]

Ik ben zelf ook altijd van zoveel mogelijk server side houden. Een webapp dus. Geen gedoe met uitrollen naar gebruikers, gebruikers die op verschillende versies van de client zitten, minder risico met figuren die een MITM proberen en het API verkeer proberen te beinvloeden. Met een web app kun je op één plek bugs fixen of features implementeren die daarna meteen voor alle gebruikers beschikbaar zijn zonder approval process/uitrol schema/trage updaters.

Toch heb ik in het verleden met klanten toch wel uiteindelijk de stap naar een native/lokale app moeten maken.

En dan zijn er natuurlijk schaalvoordelen bij het lokaal door apps laten uitvoeren van bepaalde zaken. Een paar miljoen gebruikers server side is vaak nog best te doen, honderden miljoenen of miljarden is een ander verhaal. Ik denk dat Facebook zo’n loodzware app heeft (mijn FB app gebruikt makkelijk 25% van al mijn batterijcapaciteit over een periode van 24 uur) omdat ze veel lokaal laten afhandelen. Ik kan nog opvallend veel in mijn FB app, inclusief posten, als ik weer eens drie kwartier in de metro zit zonder netwerk.

Met een lokale app kun je onder andere push notificaties sturen of mensen hun lokatie volgen als je dat graag wil. Verder is het voor marketing belangrijk omdat sommige mensen de app via een app store vinden en zijn er veel mensen die, zodra ze horen over een nieuwe dienst, er vanuit gaan dat hij in hun app store te vinden is “anders bestaat het niet”.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 02:13]

[johnkeates]

Een WebApp geeft juist meer MITM en API problemen, je hebt nu niet allen de API die je met je SPA gebruikt, maar ook de SPA zelf die je gaat zitten downloaden. Dat is feitelijk dubbel kwetsbaar.

Je kan je ook afvragen hoe veel zin het heeft om te doen alsof je een 'app' hebt als je dus eigenlijk gewoon een website hebt. Ga dan gewoon gebruikers naar de website leiden in plaats van doen alsof het een app is. En als ze perse een directe link naar je web ding willen, dan kunnen ze een homescreen bookmark maken.

[Gamebuster]

dan kunnen ze een homescreen bookmark maken.

Die feature snappen mensen echt niet. Ze doen het gewoon niet, vinden het te ingewikkeld of hebben er geen zin in. Alleen als het in de app-store staat vinden mensen het cool, ook al krijg je het voor elkaar om een app die een webpagina inlaadt in de store te krijgen (wat me ook wel eens gelukt is)

[Reactie gewijzigd door Gamebuster op 23 juli 2024 02:13]

[johnkeates]

Dus in plaats van het probleem aan te pakken is het beter om de kwaliteit van de App Store te verminderen?

Ik denk dat je beter gewoon een goede instructie of verbetering aan de homescreen bookmarks kan maken in plaats van net-niet-helemaal apps in de store proberen te drukken.

[Gamebuster]

Daar ben ik het mee eens. In praktijk zal je echter allemaal websites krijgen die gewoon de benodigde meta-tags toevoegen en krijg je overal de "hey! ik ben ook een app! klik hier!" melding en verliest men het vertrouwen in die knop.

[supersnathan94]

meta Tags? Dit moet je gewoon zelf implementeren als Javascript popup waarmee je mensen uitlegt hoe ze dat doen indien ze het willen.

[Gamebuster]

Ik bedoel als Apple een melding zou tonen aan de gebruiker dat de website waar je op zit geschikt is om op je homepage te zetten

[supersnathan94]

Iedere website is geschikt om op je springboard te zetten. Het is letterlijk een bookmark met favIcon als icoontje.

[Origin64]

Laten we wel wezen, het probleem is de walled garden.

[johnkeates]

Nee, dat is het probleem helemaal niet, en dat heeft er ook niks mee te maken.

[Origin64]

Tuurlijk wel. Als Apple niet probeerde om developers dingen op te leggen door allerlei arbitraire eisen te stellen dan zou dit probleem niet bestaan.

[johnkeates]

Wat is dat nou weer voor onzin. Het is gewoon een platform van een bedrijf waar regels voor gelden. Als je mee wil doen, dan moet je je aan de regels houden, en als je je niet aan de regels wil houden, dan moet je niet mee doen. Wat is daar nou zo moeilijk aan?

[Origin64]

Als de regels nou alleen regels waren van geen porno of dat soort dingen zou het niet moeilijk zijn. Apple maakt het moeilijk.

[johnkeates]

Dus om dat het niet bevalt of niet 'makkelijk genoeg' is is het automatisch allemaal boos en eng? Ik denk dat het niet anders is dan andere bedrijven die regels hebben voor hun eigen platform.

[Origin64]

Het is niet anders, maar dat maakt het nog niet goed. Google en MS zijn ook verkeerd bezig. Er is overigens wel wat verschil; op Android hoef je bijv. je device niet te rooten om buiten de app store om te kunnen installeren.

Hoe meer eisen een platform stelt, hoe meer het een bepaalde kwaliteit wil garanderen, hoe meer het innovatie drukt en hoe meer het juist een template oplegt die de diversiteit van aangeboden applicaties verkleint. Het is een trade off. Imo verliest de gebruiker bij deze wijziging in het beleid van Apple meer aanbod dan ze er kwaliteit voor terugkrijgen. zoals het artikel stelt hebben veel bedrijven niet de mogelijkheid een app zonder template te ontwikkelen.

[Reactie gewijzigd door Origin64 op 23 juli 2024 02:13]

[johnkeates]

Bij iOS kan je ook gewoon zelf software buiten de store om installeren, je maakt een gratis developer account aan (dus niet de betaalde versie) en dan kan je dat al doen. Zelfde als bij Microsoft dus.

Iedereen loopt altijd over Apple te mekkeren om dat dat gewoon hun favoriete flame-doel is, terwijl de meeste klaag-verhalen gewoon niet onderbouwd zijn.

[Origin64]

een nieuwe account maken is nog steeds meer werk dan 1 vinkje in de settings aanzetten. een hogere drempel betekent dat minder mensen het doen.

sinds wanneer bestaat die gratis test account optie eigenlijk? ik had er nog niet van gehoord. vroeger was het toch wel zo dat je een dev account moest hebben om te sideloaden?

[johnkeates]

Het bestaat al c.a. 5 jaar. Bij Microsoft ongeveer een jaartje langer.

Een vinkje aanzetten is te makkelijk en daarmee ook heel goed te misbruiken. Bij Android heb je hetzelfde malware probleem als bij Windows desktop, iets waar Windows mobile, iOS, macOS, Tizen, Meego enz. geen last van hebben.

[Reactie gewijzigd door johnkeates op 23 juli 2024 02:13]

[Origin64]

ok interessant, dat maakt het wat minder erg dat apple dit soort idiote restricties oplegt in de store.

[gron74]

Een app is op een telefoon beter en vooral makkelijker vindbaar dan een website. Veel bedrijven hebben inderdaad genoeg aan een website. Heb je geen speciale funtionaliteit nodig, zoals de camera of offline gebruik, dan is een app niet echt nodig. Met een app heb je mogelijk iets minder dataverbruik omdat bepaalde delen al op je telefoon aanwezig zijn.

Ik ben zelf app ontwikkelaar en ik vind de discussie best lastig. Ik zie vooral marketingargumenten voor eenvoudige apps (website apps zeg maar). Vroeger was dataverbruik misschien nog een argument, maar tegenwoordig speelt dat ook bijna geen rol meer.

[Zenomyscus]

Bedrijfsmatig heb ik 'apps' via webview ontwikkeld en één van de voordelen is dat je het framework kunt gebruiken om direct te kunnen communiceren met bijvoorbeeld hardware. Je bent daardoor niet afhankelijk van (verschillende) browserimplementaties zoals de navigator.getUserMedia of het ophalen van je locatie. Daarnaast is het fijn om bepaalde gegevens op te slaan zonder dat je daarvoor cookies nodig hebt en heb je extra device informatie tot je beschikking. Hoewel de view veelal hetzelfde is, kan een app via webview beter als 'native' aanvoelen dan een website. Daarnaast heb je de URL-balk niet nodig en sluit de app netjes aan op de rest. Al met al ben ik erg tevreden over webview en de mogelijkheden. Sinds enkele maanden worden soortgelijke apps ook in de Apple store geaccepteerd. Voorheen werd daar moeilijker over gedaan, dus het is jammer te horen dat het nu toch weer moeilijk gaat worden.

[ExIT]

Native features. Push notificaties bijvoorbeeld. Apple weigert dit dusver aan webapplicaties aan te bieden. Met websockets kan dit technisch perfect en efficient.

[j0pp3rtA]

Omdat Safari op ios lang niet alles ondersteund zoals service workers...

[RobIII]

Wat Apple in 2018 lijkt te willen is dat elke Jan Doedel zelf registreert als developer (papierwinkel, voorwaarden, etc) en daarmee méér inkomsten oplevert.

Die, wat, €100 per jaar? Ja daar is het ze om te doen! Een enkele app (template of niet) die een beetje populair wordt levert ordes van grootte meer op.
Nee, dit is gewoon een kwestie van je appstore schoon houden van meuk en honderdendertien-in-een-dozijn apps ("shovelware") om zo je ecosysteem gezond(er) houden.

[Grrrrrene]

[...]

Die, wat, €100 per jaar? Ja daar is het ze om te doen! Een enkele app (template of niet) die een beetje populair wordt levert ordes van grootte meer op.
Nee, dit is gewoon een kwestie van je appstore schoon houden van meuk en honderdendertien-in-een-dozijn apps ("shovelware") om zo je ecosysteem gezond(er) houden.

100 euro per jaar van honderdduizenden developers is vele tientallen miljoenen aan inkomsten, ieder jaar weer. De bedrijven die hier gebruik van maken krijgen ook bijzonder weinig tijd om de boel te fixen. Ik bedoel: 1 januari is de deadline en met de feestdagen eraf blijft er goed 2 weken over om de boel op de rit te krijgen.

[Myquandro]

Nieuwe versies komen niet meer door de controle heen na januari, er staat nergens iets over dat al bestaande apps verwijderd zouden worden. Dat betekent dus dat als je een update wil uitvoeren je dat nu moet doen, of daarmee moet wachten tot je de app zodanig hebt aangepast dat hij wel voldoet aan de voorwaarden. Heb je geen update in de komende tijd dan zal je ook weinig merken van deze nieuwe stappen die Apple neemt.

[Verwijderd]

[...]
100 euro per jaar van honderdduizenden developers is vele tientallen miljoenen aan inkomsten, ieder jaar weer.

Maar Apple doet daar wel wat voor nietwaar? Je betaald het niet om je iPhone APP ontwikkelaar te mogen noemen.

En weinig tijd? Iedereen wist dat dit eraan zat te komen, de regels staan al jaren vast.

[supersnathan94]

Die honderd eu per jaar krijgen ze nu ook want die dudes zijn gewoon als dev geregistreerd. Apple gerft nu alleen aan dat die devs wat beter hun best moeten doen en hun app kwaliteit omhoog moeten trekken volgens de richtlijnen die er al enkele jaren zijn.

[ToFast]

Dat het een kwestie is van schoonhouden van meuk ben ik ook met je eens, maar het verdienmodel mag zeker wel aangehaald worden. Als ik van elk mens op de wereld ook maar 1 cent krijg, dan ben ik rijk

[ExIT]

Niet alleen die 100 euro. Minder template ontwerpen via webapps betekend indirect dat ze ook meer xcode, osx en apple hardware verkopen. Alles bij elkaar spreek je over enorme bedragen.

[rexgildo]

Wat een onzin. Als ze nu al in de store te vinden zijn dan hebben ze al Apple hardware. Zonder kan niet, want je moet je app bouwen in Xcode dat uitsluitend draait op macOS. MacOS wordt meegeleverd met je hardware, xcode is een gratis download. Pas als je wil publiceren in de store moet je een betaalde developer-account hebben a €100,- pj.
Dit gaat niet over geld, dit gaat over kwaliteit van apps.

[ExIT]

Denk er zo eens over na: nu kan iedereen via een handvol grote partijen zelf een app maken, via een website, op basis van een template. Deze app komt onder de naam van de grote partij in de store.

Straks worden templates geweigerd. Apps zullen doordoor veel vaker door verschillende (kleinere) makers worden ontwikkeld. Dit leid tot meer inkomsten, direct en indirect voor Apple.

[willyb]

Zou een App zoals de verbruiksmanager van Essent dan eindelijk worden geweerd? Het geeft echt zo'n half-half gevoel, dat gewoon een responsive website beter had geweest.

[xoniq]

Zelfde met apps als die van Tele2. Nooit zo’n slechte app gezien.

[supersnathan94]

Na iedere halve update weer opnieuw inloggen. Hoe irritant is dat. Doe het dan niet. Een bookmark naar de website (mijntele2.tele2.nl) werkt beter

[sympa]

We Apple wil is misschien wel dat een native app niet makkelijk naar Android geport kan worden. In de hoop meer exclusieve apps te krijgen (en minder apps, maar ze gaan er vanuit dat vooral de rommel achterblijft).
Maar je zou zeggen dat rommel-appstoch geen goede reviews krijgen en dus niet bovenaan komen in de app store. Dus dat er 'ook' rommel verkrijgbaar is moet niet erg zijn toch?

[ikweethetbeter]

We Apple wil is misschien wel dat een native app niet makkelijk naar Android geport kan worden.

Onzin, je kunt met verschillende tools platform-overstijgende apps maken, die op elk platform native code draaien.

[Verwijderd]

Vind het nergens echt op slaan.
Zolang de gebrachte content van kwaliteit is, wie ligt er dan wakker van de programmatuur zelf uit een template voortkomt?

Dit maakt natuurlijk wel de drempel hoger waardoor het minder makkelijk is om een eigen applicatie uit te brengen maar of dat nou de oplossing is?

Misschien kan iemand een stuk minder programmeren maar is de content gewoon goed.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 02:13]

[supersnathan94]

Omdat die template heel veel extra boilerplate code meeneemt die er gewoon voor zorgt dat er meer resources nodig zijn. Bijvoorbeeld grotere footprint qua opslag en geheugen en/of meer berekeningen op de CPU door de extra laag ertussen.

Zie het als een virtuele machine. Iedereen hier weet dat die extra abstractielaag meer resources kost.

[Verwijderd]

Zullen we Zend, ioncube, Wordpress en vele andere frameworks en dat soort dingen dan ook maar van het internet verbannen?

Want ja ach, overhead.

Begrijp me niet verkeerd ik ben een oude rot met vele jaren prrogrammeerervaring en zie het zelf als een kunst om optimale code te schrijven maar dan nog vind ik dit geen goed idee.

[supersnathan94]

Tuurlijk niet. Frameworks zijn een totaal ander dinggetje dan dit soort template apps.

Nee een framework heb je nodig voor basisdingen in je programmatuur. Zoals veiligheid en componentscheiding. Een template app als dit voegt alleen een komplete browser toe aan je javascript code en die templates zijn vaak nog eens ontzettend onveilig en ook een issue voor resource leaking.

Er is een verschil tussen extra code en heel veel extra code. Er is ook een reden waarom steeds meer websites afstappen van JQuery. JS zelf heeft nu goed werkende alternatieven die soms een paar regels extra nodig hebben, maar wel voorkomen dat je 40K regels code moet importeren waarvan je geen idee hebt wat het allemaal doet en kan.

[Verwijderd]

Had al een vermoeden dat je vast zou happen op het woord framework en zo mis je het punt van vergelijken dus.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 02:13]

[supersnathan94]

Nee je punt is scheef. Een framework geeft structuur aan je programma. Zonder ga je gewoon ruk functionaliteit opleveren en kost het ontzettend veel tijd om het secure en netjes gescheiden te krijgen. Kijk bijvoorbeeld naar grote angular projecten. Er is no way dat je routing en modulairization op een dergelijke manier zelf voor elkaar gaat krijgen zonder ernstige security problemen of buggy code.

Een template app maakt vaak gebruik van een browser zonder interface waarin je gewoon een beetje HTML en javascript in elkaar flanst. Dat is in die zin dus heel anders dan een framework. Zonder die template is de applicatie nog net zo ruk en draait deze gewoon als app in een browser. Het template zorgt niet voor code die security in je Scripts toevoegt, waar Angular, Zend en Laravel dat bijvoorbeeld wel doen en daarnaast structuur in je code toevoegen.

[NoobishPro]

Zijn punt is niet scheef.
Jij hebt ook niet geheel ongelijk, maar deels wel.

Ten eerste;
Een framework is reten makkelijk zelf te bouwen. "Er is no way dat je routing en modulairization op een dergelijke manier zelf voor elkaar gaat krijgen zonder ernstige security problemen of buggy code. "
-- Nee, en daarom heb ik dat gebouwd in 35 minuten tijd...

Het klinkt misschien aannemelijk, maar is de 94 in jouw username je geboortejaar? Want dan kan ik mij jouw standpunt enigszins inbeelden. Tegenwoordig wordt elke programmeur opeens grootgebracht met "Kijk hoe geweldig frameworks zijn!" en "Je hoeft het wiel niet opnieuw uit te vinden hoor!"

Nou, frameworks zijn helemaal niet zo top als je denkt. Daarom zijn er ook zo bizar veel. Ze denken allemaal het beter te kunnen doen dan een ander en dat blijft consistent zo. Als er iets buggevoelig is en security issues heeft is het wel een gigantisch kant-en-klaar framework. Mijn home-made frameworks hebben zelden updates of onderhoud nodig en zijn vaak juist veiliger.

Anyway, back to the point;
@Dr.Zeno probeert geloof ik duidelijk te maken, dat het tegenwoordig een beetje de norm is om programmatuur te gebruiken welke kant-en-klare code uitspuugt. Deze code genereert vaak gigantische hoeveelheden overhead. Ook veel moderne truukjes en server-side frameworks doen dat. Het veroorzaakt nou eenmaal hele gigantische bakken met if-statements, checks bovenop checks, queries bovenop queries en binnen al die dingen nog eens 35 keer dezelfde dingen om iets uit te poepen wat eigenlijk in 5 regels code van een goede programmeur geschreven kon worden. -- Het punt zijnde dat, als 80% van't internet ondertussen zo in elkaar zit, waarom niet een paar apps? Niemand geeft er blijkbaar iets om.

"Zonder die template is de applicatie nog net zo ruk en draait deze gewoon als app in een browser."
-- Ook deze stelling is simpelweg niet waar.
- Ten eerste brengt een web-app enkele voordelen met zich mee zoals offline gebruiksmogelijkheden, toegang tot telefoonfuncties (zoals de camera, vibraties en bestanden) en push berichten.
- Ten tweede, kan zo'n app aanzienlijk veel sneller zijn dan een slecht geprogrammeerde native app (vooral welke dus gebouwd worden met template poepmachines). Als je echt veel spul lokaal af gaat vangen zal een native app altijd sneller zijn en dit is vanzelf sprekend, maar wanneer je veel server-side afvangt kan een web-app zelfs sneller zijn. Het is maar net waar je voor gaat... Ik heb juist enkele native apps vervangen met web-apps voor een fijnere interface en betere werking specifiek voor bepaalde doelgroepen. Deze doelgroepen zijn daar bijzonder blij mee maar apple staat hier vaak in de weg. Een groot deel van deze doelgroepen is dan ook als bedrijf geheel overgestapt naar android, puur om de Apple drama's te vermijden.


"Het template zorgt niet voor code die security in je Scripts toevoegt, waar Angular, Zend en Laravel dat bijvoorbeeld wel doen en daarnaast structuur in je code toevoegen."

Deze frameworks voegen praktisch geen security toe. Er zijn bepaalde simpele handelingen (vooral SQL-injection gerelateerd) waar deze frameworks rekening mee houden voor je.
Het punt is echter, dat veiligheid compleet binnen de handen van de programmeur ligt. De programmeur bepaald wat er precies gebeurd en als jij dekking gaat zoeken achter de frameworks kun je daar goed veel spijt van krijgen.

Waarom?
Ten eerste; frameworks zijn zo lek als een mandje. Het is maar net de vraag wanneer de volgende exploit gevonden word.
Ten tweede; Het ligt alsnog in de hand van de programmeur. De programmeur kan met 1 regel code alle beveiligingen van het framework ongedaan maken.
Ten derde; Een groot deel van security heeft met server settings te maken. Staat geheel los van deze frameworks.
ten vierde; Angular is een javascript framework. Dit is front-end, client-side. Dit doet weinig aan security, het maakt alles enkel 'strict' waardoor jij er zelf beter op gaat letten. Dan kun je het echter nog steeds erg makkelijk verknallen.

Het schrijven van een eigen framework en/of je wat beter verdiepen in het programmeren met de taal i.p.v. één of andere vervorming van een framework, zal je veel meer begrip geven van hoe code werkt en waarom het zo werkt. Dit raad ik dan ook elke stagiair(e) aan welke ik begeleid.

Frameworks en templating systemen zijn uiteindelijk niet erg anders dan slechte medicatie in het ziekenhuis. Je krijgt een pilletje en dit pilletje blijkt bijwerkingen te hebben. Vervolgens krijg je nog 3 pillen om deze bijwerkingen te verhelpen en dan krijg je voor elk van die 3 pillen weer 2 pillen, terwijl een gezond dieet al deze problemen al zou voorkomen. Dit is een oneindige cyclus.

Mijn home-made websites zonder kant-en-klaar frameworks zijn tot op de dag nog niet gehackt (kan ook te maken hebben met de kleine schaal natuurlijk, maar ook niet door bots e.d.) en zonder al die troep hebben mijn producten loadtimes van zo'n 70 tot 450ms... zonder caching. Elk van mijn frameworkloze websites scoort in de top 5% (Degene die er voor betalen zelfs in de top 1%) snelste websites ter wereld. Dit is iets waar ik niet eens moeite voor doe, maar iets wat gewoon gebeurd omdat ik geen 3rd-party crap injecteer in mijn projecten.

Zoals ik al zei; Die routing en modulairization waar jij het over hebt, heb ik in 35 minuten geschreven, --3 jaar geleden-- en daar heb ik nu nog steeds baat bij. Dit komt omdat ik de basis van het programmeren begrijp i.p.v. afhankelijk te zijn van partijen van 3e.

Ik ben erg blij voor je dat je passie hebt voor programmeren en dat is iets waardoor je waarschijnlijk ver zal komen, maar onderschat niet de kracht van seniore programmeurs. Toen ik nog maar net programmeerde sprak ik ze ook maar al te graag tegen met al mijn kennis over de nieuwste snufjes, maar het feit is dat de nieuwste snufjes zo fantastisch nog niet zijn.
Hoe verder het terug gaat naar de basics, hoe beter het product zal zijn.

Just my 2 cents, ik hoop dat je er wat aan hebt. Het was zeker niet mijn intentie om je te beledigen oid maar om je een nieuw perspectief te bieden.

[Reactie gewijzigd door NoobishPro op 23 juli 2024 02:13]

[supersnathan94]

Bedankt voor je reactie. Dit voegt dan ook daadwerkelijk toe aan het verhaal waaruit ook maar weer eens blijkt dat goed programmeerwerk de noodzaak voor dit soort template apps wegneemt. Kijk ik ben ook ooit eens begonnen met een sleur en pleur angular2 template, maar wat een gedrocht is dat geworden XD. Zelf gewoon opnieuw beginnen is dan veel beter, Applicaties als Spring web/MVC maken het daarbij ook nog leuk om te doen.

Maar je zet juist mijn punt wat meer kracht bij. Het verschil tussen framework en template is dan ook het punt wat ik probeer te maken. Waar het framework nog betekent dat je zelf moet gaan bouwen en best practices moet toepassen heeft die template App een hoog sleur en pleur gehalte.

Als zo'n browser template applicatie de GUI in elkaar laat slepen is dat meer het probleem dan dat de die browser template feitelijk niks toevoegt anders dan dat je het in de app store kunt publiceren. Rabo gebruik namelijk ook zo'n applicatie en Untappd heeft Ionic framework met een dergelijke schil. nou is die rabo app verre van goed te noemen qua snelheid), de bediening is goed en het heeft natuurlijk een hoge security eis waar rekening mee moet worden gehouden. Untappd werkt echter perfect. Goede usability, prima UI en snelle reactie. Het kan dus prima met een framework en een browser schil, maar waar Apple nu tegenaan schopt zijn de apps zoals je die kunt kopen bij bijvoorbeeld CodeCanyon. Gewoon kant en klare applicaties waar je zelf een huisstijltje overheen plempt. Dat is nooit de bedoeling geweest (want zorgt voor veel meuk en clones) en werd ook gedoogt, aangezien de regels om dit tegen te gaan er ook al enige tijd zijn.

[lepel]

Apple staat geen apps toen die enkel een browser view zijn. Je moet een app van de grond af aan opbouwen. Heel erg irritant, ik maak prima mobiele websites en wil en kan daar niet een hele app voor gaan bouwen.

Gelukkig mag dit op Android wel, maar iOS apparaten krijgen dan maar een popup dat ze even op de deel knop moeten drukken en “toevoegen aan beginscherm” moeten kiezen. Ze zouden mij erg gelukkig maken wanneer deze functionaliteit met javascript aan te roepen is. Knopje en bam je komt in het scherm om het aan je springboard toe te voegen.

[xoniq]

Ja en dan krijg je dus websites die die functie misbruiken en die popup direct aanroepen zodra ze zien dat je op een iPhone zit. Leuk man!

[R4gnax]

Ja en dan krijg je dus websites die die functie misbruiken en die popup direct aanroepen zodra ze zien dat je op een iPhone zit. Leuk man!

Je kunt het zo opzetten dat deze functionaliteit alleen vanuit een directe gebruikersinteractie aan te roepen is. Zal niet de eerste keer zijn dat zoiets in een browser geplaatst wordt.

[supersnathan94]

Dat is het nu toch ook al? Ik ken genoeg websites die de popup nu ook al hebben. Iets als dit: http://static.cubiq.org/uploads/2011/01/ath-preview.png

[R4gnax]

Dat is het nu toch ook al? Ik ken genoeg websites die de popup nu ook al hebben. Iets als dit: http://static.cubiq.org/uploads/2011/01/ath-preview.png

Nee. Dat is een met in-pagina HTML gerenderde tooltip, die de gebruiker instrueert om handmatig de native methode van iOS Safari te gebruiken om een pagina op het home screen te pinnen.

Waar ik het over heb is een arbitrair HTML element wat helemaal in het design van een site op zou kunnen gaan, waarbij een klik van de gebruiker een prompt activeert "wil je deze site op je homescreen pinnen? Ja/Nee" en het dan ook meteen doet. En om het spammen er van tegen te gaan, deze functionaliteit dan enkel aangeroepen kan worden vanuit een script wat gestart is via een gebruikersinteractie zoals een click event.

[supersnathan94]

Dat snap ik. Maar die functies ontbreekt dus voor hele goede redenen. Je kunt namelijk ook prima een onclick genereren in javascript en dus is het vatbaar voor spam en misuse.

Zoek ook maar eens naar de “self retweeting tweet”.

[R4gnax]

Dat snap ik. Maar die functies ontbreekt dus voor hele goede redenen. Je kunt namelijk ook prima een onclick genereren in javascript en dus is het vatbaar voor spam en misuse.

Ja; je kunt een synthetisch click event maken, maar dat is niet hetzelfde als een echt click event wat via gebruikersinteractie tot stand komt en via de event loop uitgevoerd wordt. Browsers kennen het verschil en kunnen (en moeten!) bepaalde APIs blokkeren als ze aangeroepen worden in code die niet draait als gevolg van een gebruikersinteractie.

De fullscreen API is een mooi voorbeeld daar van:
https://fullscreen.spec.w...element-requestfullscreen
https://fullscreen.spec.w...wed-to-request-fullscreen

[HenkEisDS]

Gebeurt nu ook al met notifications in Chrome. Erg irritant en iets dat ik blokkeer, alleen voor whatsapp web en was crm-plugins wil ik het toestaan.

[SPee]

Of Apple voegt aan zijn store Webapps toe, die enkel een linkje installeren.
Wel in de appstore, geen daadwerkelijke app.

[lepel]

Zoals r4gnax al zei, je koppelt dit aan een actie van een gebruiker. Probeer maar eens audio af te spelen op een iOS apparaat, dat lukt je niet zonder het aan een click oid te koppelen.

[Vlizzjeffrey]

Precies dit, Apple heeft weer een manier gevonden voor wat extra inkomsten, ze verdienen nog niet genoeg.

[supersnathan94]

Die inkomsten hadden ze al. Devvers zijn gewoon geregistreerd.

[robvanwijk]

Apple staat het gebruik van templates en appgenerators niet toe om de kwaliteit van de applicaties hoog te houden. Apps die op dergelijke wijze zijn gebouwd zijn vaker van lage kwaliteit dan software die volledig zelfstandig is gebouwd.

Is het dan een goede oplossing om het gebruik van templates te verbieden? Zou het niet veel handiger zijn om in te zetten op het gebruik van kwalitatief goede templates? Dan kun je alle apps die van dat template gebruikmaken in één keer van goede kwaliteit maken. Met andere woorden: schrijf niet de bedrijven aan die hun apps bouwen op basis van een template, maar de aanbieders van brakke templates.

[supersnathan94]

Door de gebruikers van de brakke templates aan te schrijven heb je natuurlijk meer draagvlak. “Hee man onze app komt niet meer door de controle omdat jullie betaalde dienst niet goed genoeg is. Hoe zit dat? Ik betaal jullie toch om fatsoenlijk werk af te peveren wat de store goedkeuringsprocedure doorkomt? Step up your game, want anders moeten we het contract ontbinden”.

[robvanwijk]

"Step up your game, want anders moeten we het contract ontbinden"

Ik vrees dat de leverancier dan antwoordt "Apple heeft eenzijdig de regels aangepast, wij claimen overmacht, dus ja, laten we het contract inderdaad maar ontbinden (zonder dat jullie geld terugkrijgen)."

Apple staat het gebruik van templates en appgenerators niet toe

Klinkt mij niet in de oren alsof het de moeite loont om geld te investeren in het maken van betere templates; dikke kans dat dat weggegooid geld zou zijn.

[supersnathan94]

Ik vrees dat de leverancier dan antwoordt "Apple heeft eenzijdig de regels aangepast,

Komen ze gelukkig niet mee weg aangezien die regeltjes al jaren bestaan.

[Mathi159]

Dan kunnen ze toch ook gewoon een paar templates goedkeuren? Alsof het zelf bouwen van een app een hogere kwaliteit oplevert. Groot team dat een template onderhoud tegenover de lokale shoarmaboer die een student inhuurt.

[BikkelZ]

Of erger nog gedwongen wordt via grote spelers als Uber Food te gaan werken in plaats van onafhankelijk.

[BikkelZ]

Het probleem is dat sommige diensten gewoon echt het zelfde zijn tussen verschillende bedrijven. Bijvoorbeeld restaurants met een bezorgdienst inclusief push notificaties en bezorger app. Te duur voor familiebedrijfjes vanaf de grond te schrijven en ook compleet onnodig.

Ik schrijf zelf ook apps die door meerdere bedrijven onder eigen layout gebruikt worden dus dit raakt me direct. Toch is het wel nodig om de applicaties te splitsen.

[mutley69]

Ik ben van mening dat Apple gewoon veel te ver gaat in z'n bemoeienissen - en het is dan ook antireclame voor de gesloten omgevingen die we aan't krijgen zijn met allerhande stores - of dat nu om Apple, Microsoft, Google, Amazon of wie dan ook gaat - één store voor uw aparaat is een dure gouden kooi - waarbij u af/uit-persbaar wordt.
Zelf probeer ik zo veel mogelijk buiten schot te blijven - maar het wordt haast onmogelijk - en dat is een zeer pijnlijke conclusie - het liberalisme is ons in ons ongeluk aan't storten - de heren politici doen hun werk niet! Hou de markt vrij - hou de markt open - verbiedt met eenvoudige, duidelijke maar hyperstrakke wetgeving het opsluiten van de consument in één gesloten eco-store-systeem.

[Dreeass]

Ik werk voor een dienst die dit allemaal onder 1 app beschikbaar maakt. In mijn ogen gaan je klanten niet perse voor jouw zaak de applicatie installeren en dat zien we ook vaker als we kijken naar de nieuwe apps die gebruikers jaarlijks installeren. Het aantal nieuwe apps dat worden gedownload ligt behoorlijk laag.

Het downloaden van een app per winkel is ook niet echt gemakkelijk en geeft de winkel ook geen publiciteit in een app dat al bestaand gebruikers en potentiële klanten heeft. Je ziet mij niet een applicatie downloaden specifiek voor je winkel, dan ga ik wel ergens anders heen of bel ik als ik iets op voorhand wil bestellen. Je kan mij enkel de app laten downloaden als ik werkelijk een enorm trouwe klant ben, maar dat ben ik namelijk nergens eerlijk gezegd.

[BikkelZ]

Ik schrijf apps waarvan ik weet dat nooit meer dan 80 mensen hem gaan gebruiken. Maar voor die mensen is het wel een super belangrijke app.

Ook zijn er wel degelijk mensen die een app hebben voor een losse winkel, ik heb er een voor de ijsboer op de hoek. Als die weer wat nieuws bedacht heeft dan krijg ik een push notificatie. Juist de "whales" bereik je met een app.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 02:13]

[swhnld]

Jammer dat ze niet gewoon het hele artikel overgenomen hadden, daar staan de redenen in:

What’s unfortunate about the expanded policy enforcement is that these app makers specifically target the small business market. They build apps for businesses that don’t have the internal resources to build their own apps or can’t afford to hire a custom shop to design a new iOS app from scratch.

Instead, these companies help small businesses like local retailers, restaurants, small fitness studios, nonprofits, churches and other organizations to create an app presence using templates, drag-and-drop wizards and various tools to put together a more basic app that can then be customized further with their own branding and images.

These may not be the most-used apps, to be sure, but for the niche audiences they serve – say, for example, customers of a local pizza place that would rather have its own app rather than paying the fees associated with being on a food ordering platform like Seamless/GrubHub or Uber Eats – they serve a useful purpose.

As one app builder put it, the decision to limit these small businesses’ ability to compete on the App Store is as if a web hosting company said that they would no longer allow web pages built with WordPress templates or those made using website wizards from services like Wix or Squarespace.

[iceheart]

As one app builder put it, the decision to limit these small businesses’ ability to compete on the App Store is as if a web hosting company said that they would no longer allow web pages built with WordPress templates or those made using website wizards from services like Wix or Squarespace.

Was het maar zo'n feest; dit is véél ingrijpender. Als je webhost geen WP oid site meer wil hosten vind je een andere host. Geen probleem, je kunt dezelfde doelgroep blijven bereiken.
Nu heb je gewoon met iets van ~30% van je doelgroep een welhaast onoverkomelijke hobbel om nog dat klantcontact te kunnen maken als je niet naar de pijpen van deze dienstverlener besluit te dansen. Da's een veel groter probleem voor dit soort (klein)zakelijke belangen.

[Aeternum]

ok, maar geldt dit dan ook als je frameworks als ionic e.d. gebruikt om je app mee op te bouwen?

[inbedrijf]

Ik kan bij deze bevestigen dat Apple dit heel hard aan het verwerken is, wij hebben heel veel apps in de appstore, die min of meer allemaal hetzelfde doen, alleen ander kleurtje en bedrijfsnaam. Afgelopen maand de melding gehad van apple dat we geen apps zoals deze mogen aanbieden. Aardig wat contact gehad maar allemaal zonder resultaat. De apps worden gerejected onder 4.3 App Store Review Guideline.
_{4.3 Spam
Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, and Kama Sutra apps already. Spamming the store may lead to your removal from the Developer Program.}

Als je hierop googled zul je al veel resultaten vinden waarbij ontwikkelaars allemaal tegen hetzelfde aan lopen
https://forums.developer.apple.com/thread/83091

[swhnld]

Wat helpt is je apps regio gebonden te maken en extra developer ID's te kopen zodat de apps onder unieke ID's gepubliceerd worden..

[Spekkie88]

Wat wordt er precies verstaan onder template? Komen apps die crosscompiled zijn met bijvoorbeeld xamarin dan straks ook niet meer door de controle?

[RobIII]

Nee het gaat om apps die "low effort" zijn. Die uit een appgenerator komen fietsen aan de lopende band. En die pretenderen heel wat te zijn maar niks bieden / toevoegen maar hopen op de arme consument die perongeluk de verkeerde (maar héél toevallig "gelijkende" appnaam en icoon hebben) downloadt. Rommel en meuk dus. Doei Ik zal het niet missen en vind het een fantastisch besluit

[BikkelZ]

Dat is niet waar, het gaat ook om bedrijven die bijvoorbeeld een bezorg app bouwen voor de pizzaboer op de hoek zodat hij zijn klanten een app die qua kwaliteit met Domino's Pizza op kan boksen onder eigen label in de App Store kan hebben.

Als dat niet meer kan dan moeten ze met grote bedrijven als Uber Food in zee gaan.


Terwijl het hele proces van bestellen en bezorgen van pizza gewoon overal het zelfde is. Natuurlijk kan dat met een template.

[jabwd]

eerst zien dan geloven. Het is leuk dat je het direct kopieert van het originelenartikel; maar laten we eerst even afwachten met conclusies trekken die we niet kunnen trekken totdat de data binnen is.

Laten we niet vergeten hoeveel devs huilen over het review process waar ze in 99% van de cases gewoon een bad actor waren en slechte dingen mee weg probeerden te komen.

dit gaat waarschijnlijk veel meer in op asset flips zoals je op steam ziet: goede zaak dan.

[Reactie gewijzigd door jabwd op 23 juli 2024 02:13]

[francoski]

Ik heb ervaring met het review proces van Apple. Het aanleveren en uploaden is complex, onlogisch, rommelig, verre van bug vrij en bij iedere versie update weer compleet anders. Maar als je daar doorheen bent en bij de review komt, wordt er écht veel doorgelaten. Zowel qua stijl als qua functioneren. Als je daar niet aan voldoet is het inderdaad een prut applicatie.

[Grrrrrene]

Maar wat je omschrijft heeft feitelijk niks te maken met hoe je een app maakt, meer met de intenties van de maker. Apple heeft toch al prima stokken om mee te slaan om bijvoorbeeld een "Whatsap" met het Whatsapp-logo in een heel iets lichtere of donkerdere tint te blokkeren in hun app store? Er zullen ongetwijfeld ook legio legitieme apps met templates gemaakt worden, door mensen die wel een goed idee hebben, maar geen programmeerskills hebben om zo'n app van de grond af aan op te bouwen

[GeforceAA]

Zoals de PlayStation apps van Sony.

[Ryur]

Apps die gebouwd zijn d.m.v. Xamarin(.Forms) zijn gewoon native!
Dus daar hoef je geen zorgen om te maken.

[Verwijderd]

Ik heb weinig verstand van deze materie.

De vraag die bij mij opkomt is waarom voorheen het dus geen probleem was om templates te gebruiken?

Sterker wellicht was dit gewoon toegestaan?
Hoe zit dit nou precies?

[Cergorach]

De vraag die bij mij opkomt is waarom voorheen het dus geen probleem was om templates te gebruiken?

De hoeveelheid apps worden er steeds meer. Recentelijk hebben ze 64bit geforceerd met ios11 waardoor er een heleboel oude troep is afgevallen (op ios11). Op een gegeven moment vervalt alle support op alles ouder dan ios11 en dan kunnen ze eindelijk de oude troep uit de store trappen, nu willen ze er niet nog meer nieuwe troep bij.

Want ze moeten al die meuk beoordelen, je wil regels stellen die je geautomatiseerd kan beoordelen door er troep uit te filteren. Een makkelijke manier is om templates te herkennen, iets waar volgens Apple veel meuk mee wordt geproduceerd. Een simpele methode is dus om die er uit te filteren, scheelt een hoop troep.

En de vraag is of we wel voor elke pizzeria een app willen, want volgens een database hebben we zo een 2000! Pizzeria's in Nederland, das een heel klein pokke landje! Moet je eens voorstellen hoeveel er zijn over de hele wereld, willen we wel 800.000 pizzeria apps in de ios appstore? En dan hebben we het niet eens er over hoe vaak die krengen failliet gaan en niemand die dan even de app verwijderd... De volgende maakt weer een nieuwe app, zo heb je na jaren rustig de kans op miljoenen pizzeria apps waarvan er veel niet meer werken...

Daar komt bij dat Apple bij veel van die template troep er helemaal niets aan verdiend en het ze eigenlijk alleen maar geld kost. Een goede reden voor Apple om het er uit te slopen...

[RobIII]

De vraag die bij mij opkomt is waarom voorheen het dus geen probleem was om templates te gebruiken?

Het is toch aan Apple om de regels te veranderen? Ook al was het voorheen toegestaan? Dit is een typisch gevalletje voortschrijdend inzicht / hindsight en had meteen al verboden moeten worden maar je kunt niet álles voorzien Kudo's voor Apple dat ze deze wijziging zonder schroom (durven) doorvoeren; dit komt hun ecosysteem alleen maar ten goede.

[Reactie gewijzigd door RobIII op 23 juli 2024 02:13]

[Verwijderd]

Jaja

Dat ik altijd de standaard reactie.
Er is een verschil tussen mogen en of het redelijk is wat ze doen.

Daarbij vind ik de opmerking ze mogen doen wat ze willen zo KORT door de bocht. Brrr.

[Verwijderd]

Daarbij vind ik de opmerking ze mogen doen wat ze willen zo KORT door de bocht. Brrr.

Waarom precies?

Apple bepaalt wat er in HUN store staat, dat lijkt me niet meer dan normaal. Elke ondernemer maakt zijn eigen keuzes en omdat Apple toevallig enorm groot is doet daar niet aan af.

[Verwijderd]

Oh ja?
Werkt niet helemaal zo hoor

Stel Apple bepaald dat er alleen navigatie in mag komen van Tomtom en verder geen andere leveranciers.

Wat denk je?
Mag dat?

P.S. Juist omdat ze erg groot zijn doet het er wel degelijk toe!!!

Hint: verhaal IE Explorer en Windows.
Je zou zeggen Microsoft bepaald zelf wel in hun eigen software welke browser toch??

[Reactie gewijzigd door Verwijderd op 23 juli 2024 02:13]

[RobIII]

Er is een verschil tussen mogen en of het redelijk is wat ze doen

Hun ecosysteem, hun appstore, hun devices, hun regels. Ja ze mogen het doen; of het redelijk is is verder weinig relevant (maar ik vind het redelijk ja).

Daarbij vind ik de opmerking ze mogen doen wat ze willen zo KORT door de bocht. Brrr.

Ik vind je tegenargument (welk?) anders ook redelijk niet-onderbouwd

[Reactie gewijzigd door RobIII op 23 juli 2024 02:13]

[Verwijderd]

Ik vroeg of iemand het kon uitleggen.
Zie mijn eerste post.

Dat jij dan komt met ze mogen doen wat ze willen is dan wel onderbouwd?

[RobIII]

Ik vroeg of iemand het kon uitleggen

Ik leg je toch uit dat het hindsight is en niet alles voorzien kan worde ? En dat ze het mogen? Daarmee heb ik de eerste twee je vragen uit je eerste post beantwoord dacht ik zo. De derde is met teveel om uit te typen op m'n mobiel; maar dat doet vast iemand anders

Dat er niet staat wat jij wil horen is iets anders...

[Reactie gewijzigd door RobIII op 23 juli 2024 02:13]

[Yoshi]

nope, zo werkt het niet... Dat hebben verscheidene rechtzaken al bewezen in het verleden tegen andere tech giganten. Er bestaat nog zoiets als een vrije markt. Wederom, vind het wel positief daar niet van

[sympa]

Hun device? I want my money back, then.

[RobIII]

Oh boohoo... je weet donders goed dat ik 't niet had over "hun device" in de context van ownership. Ja, JOUW device hoor

[Reactie gewijzigd door RobIII op 23 juli 2024 02:13]

[Yoshi]

eigenlijk hadden ze ook gerust wat overleg kunnen plegen met de industie. Vind het goed, maar denk dat 1 de termijn wat kort is en 2 overleg toch ook altijd mag.

[i-chat]

ik ben blij dat ik geen iphone heb, stel je toch een voor dat je van zo'n waardeloze app afhankelijk bent.
laten we zeggen, een app om iets als een adres uit je database te halen als je onderweg bent voor zo'n functie moet je geen hele app hoeven te ontwikkelen en een webview is ook niet handig als je je geregeld ofline bent en wilt kunnen cashen.

dat je hier poep-en-scheet-apps mee kunt hinderen is leuk, maar je hinderd er ook apps mee die gewoon simpelweg niet uitgebreid genoeg zijn om een volwaardige app voor te ontwikkelen maar belangrijk genoeg zijn om er toch IETS voor te doen.

had als apple dan, de apps wel uit je store geweerd, maar niet uit je distributie platform...
dan kunnen ontwikkelaars de app wel aanbieden aan hun 'klanten' of biedt klanten meer mogelijkheden om te sideloaden.

om een voorbeeld te geven: hitler was fel tegenstander van roken, en heeft hele campagnes ertegen gevoerd, maar dat maakt hem nog geen held...

[Reactie gewijzigd door i-chat op 23 juli 2024 02:13]

[Keypunchie]

ik ben blij dat ik geen iphone heb, stel je toch een voor dat je van zo'n waardeloze app afhankelijk bent.

Als iets het waard is om te doen, is het waard om het goed te doen. Als je afhankelijk bent van iets dat verder waardeloos is, onderneem aktie.

dat je hier poep-en-scheet-apps mee kunt hinderen is leuk, maar je hinderd er ook apps mee die gewoon simpelweg niet uitgebreid genoeg zijn om een volwaardige app voor te ontwikkelen maar belangrijk genoeg zijn om er toch IETS voor te doen.

Nou, waar het hier over gaat is meer de app-variant van e-mail spam. Het is niet zozeer belangrijk genoeg, maar er valt geld mee te verdienen aan "the long end of the tail". Een template-app is bijvoorbeeld een app met informatie over een eredivisie-club voor 99 cent. En dan maak je er gewoon 18, voor elke club eentje. En anders meteen ook voor de eerste divisie. En de informatie pluk je van Wikipedia. Daar zit in principe niemand echt op te wachten, maar er zijn genoeg mensen geinteresseerd in voetbal dat je met een beetje SEO genoeg bovenaan komt te staan als ze zoeken naar hun favoriete club, zeker als dat pak-em-beet RKC is (excuus als blijkt dat zij allemaal supergoeie apps hebben).

De kosten zijn allemaal extern: het vervuilt de zoekresultaten, de hosting-kosten, het verwerken van geld terug aanvragen (meesten zullen de app deleten en denken "laat maar zitten").

Apple mag daar best wat aan doen. Sterker nog, het versterkt de waarde van hun eco-systeem dat ze dit soort dingen regelmatig opruimen.

[Chinco]

Maar in plaats van een inhoudelijke afkeur gaan ze technisch dingen uitsluiten? Daar begrijp ik niets van.

Klinkt als een zwaktebod óf een verborgen agenda.

Laat onverlet dat ik het met je eens ben dat dat soort apps geen zegen voor de mensheid is.

[SuperDre]

Tja, maar defnieer 'is het waard om het goed te doen', voor 99,9% van de gebruikers(en managers) is het voldoende als het doet wat het moet doen, hoe dat gebeurd interesseert ze niet. Wat jij classificeert als 'goed' kan voor een ander nog steeds als 'bagger' gezien worden.

[cschaake]

Ik denk dat het probleem veroorzaakt wordt door simpele templates waarbij zaken als security etc. niet goed geregeld zijn. Vaak zitten er ook veel bugs in deze apps omdat ze zonder al te veel kennis in elkaar zijn gedraged en dropped.
Persoonlijk denk ik dat dit meer een signaal is naar de template ontwikkelaars. Als er templates komen welke zelf de kwaliteit goed waarborgt (m.n. security) dan zal Apple mogelijk apps op basis van goede templates wel toestaan.
Apple wil graag dat haar appstore schoon blijft van rommelige apps. Dat was eerlijk gezegd ook voor mij een reden om van Android over te stappen op Apple.

[Verwijderd]

Ik heb al 8 jaar Android en nog nooit een slechte app gedownload.
Je moet wel bewust apps downloaden niet zomaar wat doen.

Is niet anders als met de auto rijden. De Apple auto zou begrensd zijn tot 100 km/u. De Android auto niet maar daar ligt de verantwoordelijkheid bij de gebruiker. Zo hoort het.

[Verwijderd]

Ligt toch echt aan wat je download. Ook in de App Store van Apple vind je rommel.