Apple verwijdert DOS-emulator voor iOS uit App Store

Apple gaat iDOS 2 uit zijn winkel voor iOS-apps verwijderen. De emulator voor het spelen van klassieke DOS-games is al sinds 2014 aanwezig in de App Store, maar bij een review na een recente update kwam Apple tot de conclusie dat de app de voorwaarden schendt.

De ontwikkelaar van iDOS 2, Chaoji Li, wilde onlangs een update met bugfixes voor zijn app doorvoeren, maar kreeg van Apple te horen dat deze update geweigerd werd omdat de app in strijd is met de algemene voorwaarden van de App Store. Specifiek gaat het om onderdeel 2.5.2 van deze voorwaarden, die voorschrijft dat apps geen uitvoerbare code mogen installeren of starten die de functionaliteit van de app kan aanpassen.

Bij iDOS 2 ging het om het uitvoeren van package- en imagebestanden en het toestaan van het importeren van games voor iTunes File Sharing and Files, zo kreeg Li volgens MacRumors te horen. Hij kreeg van het bedrijf twee weken de tijd om de functionaliteit te verwijderen, zo niet, dan verwijdert Apple iDOS 2. Li geeft aan dat hij hier niet aan zal voldoen, omdat het gaat om functies die kritisch zijn voor de werking van de app en gebruikers de app hebben aangeschaft voor deze functies.

In 2010 verscheen iDOS in de App Store, gevolgd door iDOS 2 in 2014. De app staat ook bekend als DOSpad en is gebaseerd op DOXBox. De app is met name bedoeld voor het draaien van klassieke DOS-games op bijvoorbeeld iPads, met bediening via touchscreen. Sinds 2020 is het mogelijk gamebestanden te uploaden in iDOS, waaronder via iCloud-opslag, waar Apple nu bezwaar tegen maakt.

iDOS 2

Door Olaf van Miltenburg

Nieuwscoördinator

23-07-2021 • 11:32

235

Reacties (235)

235
227
97
14
0
92
Wijzig sortering
Zolang Apple zo graag niet aan sideloading wil, kan ze dan niet net-zogoed een berg disclaimers/popups smijten bij apps die dit wél doen/willen doen?
Er is wat te zeggen voor het willen beschermen van gebruikers, maar er zijn nou eenmaal méér opties daarvoor dan afschermen... zoals bijvoorbeeld een manier aanbieden om dingen in een container te kunnen runnen? Als appmaker lijk je dat niet zelf te mogen implementeren va wege dezelfee regel; maar apple zou dat prima en veilig moeten kunnen regelen.

En hoe zit het tevens met klanten die reeds voor de app betaald hadden?

[Reactie gewijzigd door Annihlator op 22 juli 2024 15:42]

Zolang Apple zo graag niet aan sideloading wil, kan ze dan niet net-zogoed een berg disclaimers/popups smijten bij apps die dit wél doen/willen doen?
Gebruikers een keuze geven is geen filosofie bij Apple. Apple bepaalt, gebruiker accepteert of stapt uit het ecosysteem. Dat is de prijs van een gesloten speeltuin.
En hoe zit het tevens met klanten die reeds voor de app betaald hadden?
Die mogen dat uitvechten met de aanbieder, aldus Apple. ;)

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:42]

Gebruikers een keuze geven is geen filosofie bij Apple. Apple bepaalt, gebruiker accepteert of stapt uit het ecosysteem. Dat is de prijs van een gesloten speeltuin.
Ik ben het helemaal met je eens, maar door je verwoording zou iemand dat kunnen opvatten als iets dat per definitie slecht is. Ik ben een groot voorstander van Linux, waar alles open is, maar heb ook met veel plezier met producten van Apple gewerkt, omdat het gesloten en voorspelbaar is. Het enige wat ik niet begrijp is de populariteit van Windows, waar een willekeurige grens getrokken wordt tussen waar je als eindgebruiker wel je eigen ding mag doen en jezelf in de voet mag schieten (bijvoorbeeld willekeurige software installeren die potentieel je hele systeem kunnen afluisteren of slopen) en wat je niet mag doen om te voorkomen dat je jezelf in de voet schiet (bijvoorbeeld willekeurige drivers installeren die potentieel je hele systeem kunnen afluisteren of slopen).
Die mogen dat uitvechten met de aanbieder, aldus Apple. ;)
Dat is niet waar. De app blijft beschikbaar voor een ieder die het heeft aangeschaft. Nieuwe updates krijg je niet.
Er vind geen sideloading plaats en volgens Li zijn er ook geen voorwaarden geschonden.

HI,

This version enables Document Browser mode, but it
- doesn't download code from internet,
- doesn't provide store front,
- only runs emulation in a small portion of screen.

We are perfectly aware of AppStore policy on interpreted code. The reason of this submission is that there are similar apps on AppStore, running js or python code. In principle, iDOS is no different. No security risk since the user code is running inside emulator within the app sandbox.

For years, we have been requested by thousands of users to enable iTunes file sharing. They really want their old DOS apps to continue to work for them on their iOS devices. So we think we should try for them.

Please let us know if there is any problem.
Dit is de de eerste helft van de voorwaarde (zonder het deel van educational apps):
2.5.2
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational ....
Zoals de ontwikkelaar aangeeft gaat de app niet uit "their bundles", niet uit de ontworpen container area, wordt er geen code gedownload, geen functionaliteit wijzigt van zichzelf of andere apps.
Dan blijft over niets over, of gaat het toch om code die uitgevoerd wordt?
Als je code kan uploaden, is dat toch hetzelfde als gedownloade code runnen? En als je een dos programma start dan verandert toch de functie van de app?
Denk dat Apple daarover valt. Zij kunnen nu niet meer zien wat de app doet.
Wel jammer.
En hoe zit het tevens met klanten die reeds voor de app betaald hadden?
Volgens mij wordt de app alleen uit de store verwijderd, niet van devices. Het enige nadeel is dat je dan geen updates meer krijgt, maar de app is volgens mij al aardig doorontwikkeld.

Overigens ook nu nog te koop (Apple verwijdert = gaat verwijderen)
Dat houdt overigens wel in dat bestaande gebruikers de app niet moeten verwijderen want dan kunnen ze deze niet opnieuw downloaden.
Is dat zo? Ik kan daar nergens iets over vinden.

Ik kan in de app-store bij 'Purchased' een lijst vinden van alle apps die ik ooit geïnstalleerd heb.

Een aantal kan ik niet meer downloaden omdat deze niet geschikt is voor mijn versie van iOS, maar de rest kan ik gewoon nog binnen halen, ook als de app niet meer in de store staat.

Voorbeeld: NOS Play
Heeft nog nooit op mijn nieuwste telefoon gestaan, maar kan ik wel downloaden en installeren.
In de store is deze niet meer te vinden (staat ook niet in 't lijstje van apps gemaakt door/voor NOS)

Misschien dat het voor apps die door Apple zijn verwijderd anders is, maar daar heb ik nog geen voorbeeld van kunnen vinden. Apple zelf zegt:
If my app is removed, will current users be able to access my app?
Yes. Your app will remain fully functional for current users. They will experience no interruption to services and will still be able to buy in-app purchases. However, we recommend that you update your app as soon as possible to reinstate it on the App Store and ensure that it remains functional and engaging for new and existing customers.
Ja raidlabs heeft inderdaad gelijk. Ik denk dat de meeste mensen die met flappy bird hebben ervaren. Nadat die verwijderd werd uit de appstore kon niemand hem opnieuw downloaden. Dat werd zelfs zo heftig, dat iphone’s met flappy bird voor vele honderden euro’s meer op marktplaats werden aangeboden
Lijkt me sterk want dan zou je je Apple ID erbij moeten verkopen.
Voor vele honderden euro's krijg je van mij de Apple ID er gratis bij.
Zou best kunnen, maar ik vraag me dan af wat Flappy Bird zo speciaal maakt?

- NOS Play is verwijderd uit de store, en kan ik nog steeds downloaden

- Flappy Bird is verwijderd uit de store, en kan je niet meer downloaden :?

Ik heb Flappy Bird nooit gekocht, dus kan het helaas niet zelf testen.

Die honderden euro's die mensen bieden voor die telefoons kan ook verklaard worden door mensen die het spel helemaal nooit hadden gekocht, dan kan je de download inderdaad niet onder 'Purchased' terugvinden.
Interessant om te zien dat er klaarblijkelijk zo’n verschillen zijn. Ik heb zelf ooit TomTom Europa als kaarten map gekocht en die kan ik ook niet meer downloaden. Sterker nog die staat niet eens in mijn aankoopgeschiedenis. Ik zie ook gratis apps die niet kan herstellen.

Ik verwacht dat het wel of niet herstellen te maken heeft met (een combi van) onderstaande zaken:
- Of de app beschikbaar is met het OS wat je draait. Zo kan ik een gratis app die outdated is voor mijn iOS versie niet meer herstellen totdat de ontwikkelaar de app bijwerkt naar een recente versie.
- Juridische gronden, mogelijk zijn om er juridische gronden waarop Apple een gekochte app beschikbaar moet houden, dit zou ook nog per regio kunnen verschillen vanwege lokale wetgeving.
- Verschillen tussen gratis en gekochte apps (mogelijk ook terug te voeren op het juridische aspect).
- 32 vs 64 bit support eventueel in combinatie met andere punten.

[Reactie gewijzigd door raidlabs op 22 juli 2024 15:42]

Ik denk dat je gelijk hebt. Valt inderdaad moeilijk een pijl op te trekken. De 32 bit apps lijken inderdaad het allemaal niet te doen. Een paar andere apps zijn geüpdatet door Apple zelf met een nieuw certificaat.
Verder geen idee wat de regels precies zijn :)
Flappy Bird is door de developer zelf verwijderd.
Dat je niet meer alle apps kan downloaden heeft volgens mij te maken met het droppen van 32-bits support door Apple in iOS 11. Apps die al geschikt waren voor 64 bits of bijgewerkt zijn kun je nog steeds allemaal installeren.
Zolang die 32-bit apps niet om andere redenen verwijderd zijn door Apple kun je ze nog vinden en downloaden op apparaten met iOS versies die nog 32-bit apps ondersteunen.
Het antwoord dat Apple hier geeft zegt nog weinig. Het geeft aan dat de app (mits niet verwijderd) blijft werken. Dat is op zich ook logisch. Het zegt niets over dat de app opnieuw gedownload kan worden.
Ja dat heb ik ervaren met de infinity Blade trilogie. Die 3 games zijn verwijderd en niet opnieuw te downloaden nadat Apple het account van Epic Games afsloot.
Bedankt voor de info, wist niet dat dat kon gebeuren. Moeilijk om hier duidelijke 'regels' over te vinden!
Anoniem: 1322 @raidlabs23 juli 2021 14:38
Volgens mij kan je deze nog wel terug vinden in je aankoop geschiedenis en dan zo installeren. Dat vind je terug onder je account in de appstore.
Ik heb zo het vermoeden dat dit niet geldt voor apps die worden verwijderd omdat ze in strijd zijn met de voorwaarden van Apple.
Klopt, maar in extreme gevallen dus ook als het hele ontwikkelaarsaccount om die reden wordt afgesloten door Apple. Dan zijn alle apps die onder dat account waren uitgegeven weg, ook uit de bibliotheek van bestaande klanten.
Ook een goede reclame stunt, nog even wat mensen overtuigen om die €5,49 te spenderen.
Apple wil ook graag het ecosysteem beschermen tegen piraterij. Wat wel nodig is, gezien hele generaties mensen het erg raar vinden om te betalen voor software.
Dat is geen generatieprobleem. In de commodore 64 tijd werden al driftig bandjes gekopieerd.
En toch.. Destijds was de verwachting dat software onredelijk duur was; tegenwoordig kosten apps wat, een euro, misschien 5 euro? De meeste in ieder geval niet meer dan dat. Maar mensen eisen tegenwoordig gewoon min of meer dat software gratis is - zich vaak niet realiserende dat het toch echt duur is om te ontwikkelen en je dat waarschijnlijk betaalt met je persoonlijke data.
Anderzijds als je betaalt met geld, betaal je vaak alsnog met je data. Bovendien is het vaak niet transparant wat een app wel niet doet aan data monetization. Daar moet je maar op vertrouwen want voor de gewone gebruiker is dat niet te verifiëren. Overigens wel eens met je punt, software ontwikkelen kost tijd en dus geld.

[Reactie gewijzigd door raidlabs op 22 juli 2024 15:42]

Ook in betaalde apps kun je nog betalen met je data.

Ik ben op zich wel voor het betalen voor apps, maar ik vind wel dat iedere ontwikkelaar op zijn minst een demoversie moet aanbieden. Ja, ik weet dat je achteraf ook je geld kunt terugvragen, maar dat is toch net iets omslachtiger. Een lite- of demoversie waar je even lekker mee kunt spelen is gewoon veel prettiger en dan kun je daarna alsnog betalen.
Ja demoversies hebben me inderdaad nog wel eens overgehaald om games te kopen, betere reclame voor games is er bijna niet en is waarschijnlijk goedkoper dan een stel influencers betalen om je game te promoten in een sneue YouTube ad.

Het klopt dat je zelfs in betaalde apps met je data betaalt maar is het feit dat dat geaccepteerd wordt niet een gevolg van gratis apps waarbij het verklaarbaar is dat ze zo hun geld terugverdienen? Lastig te zeggen natuurlijk maar volledig onethisch imho. Ik mag zelf nog wel eens het verkeer checken met Charles Proxy en adh daarvan domeinen blokkeren in mijn dns.
Ik zie trouwens steeds vaker dat apps niet 5 euro kosten, maar 5 euro per week.
En daar trap je in?
Een dubbeldeck cassette speler/opnemer was dan ook onmisbaar in die tijd. En later natuurlijk diskettes.
Sterker nog: als we het nog iets breder trekken is het zelfs nóg ouder dan de C64, want in 1970 werden ook al radio-opnames van muziek gemaakt terwijl je ook de single in kwestie/het bijbehorende album kon kopen.
Hij zegt ook hele generaties.
Dat is precies een van die generaties…

De jonge jeugd spendeert een hoop aan games en plug-ins, eerder de wat oudere generaties die uit het torrent tijdperk komen, of de C64 bandjes en later de diskettes of gebrande schijfjes die het gewend zijn er niet voor te hoeven betalen.
Anoniem: 411179 @Wolfos23 juli 2021 13:33
Dat is met een gesloten systeem als iOS niet opgelost. Meer nog, het zijn net de app stores die 'gratis' of microbetalingen als diepgewortelde verwachting bij software hebben gemaakt.

[Reactie gewijzigd door Anoniem: 411179 op 22 juli 2024 15:42]

Apple wil ook graag het ecosysteem beschermen tegen piraterij. Wat wel nodig is, gezien hele generaties mensen het erg raar vinden om te betalen voor software.
Klopt, dat vinden ze inderdaad heel raar. Als je een beetje de discussie op Tweakers volgt over zaken rond copyright en kopiëren is een ruime meerderheid van mening dat:

1) De maker geen verlies leidt want als het niet gratis was hadden ze het sowieso niet gekocht.
2) Het is geen stelen want de maker raakt niets kwijt.
3) De maker heeft genoeg andere mogelijkheden om ermee te verdienen, reclame erin verwerken en merchandising eromheen enzo.
4) Door het verspreiden van kopieen aan vrienden en familie krijgt de maker grotere bekendheid en leren meer mensen zijn product kennen. Dat is toch zeker ook flink wat waard!

Kortom, weinig reden om jouw met hard werken zuur verdiende geld aan ook gratis te kopieren software te besteden.
1) De maker geen verlies leidt want als het niet gratis was hadden ze het sowieso niet gekocht.
Zit wel een kern van waarheid in deze stelling.
Als ik een spel maak, en niemand koopt het, heb ik geen verlies, maar ook geen winst.
Naja, wellicht development tijd verlies, maar als iemand het niet koopt, en laat liggen, is niet de fout van de consument. Het zou wel netjes zijn als je ervoor betaald als het spel of whatever je bevalt. Ik heb ook wel eens wat dingen gedownload, en uiteindelijk origineel gekocht, puur omdat het het geld waard is. Achteraf kopen er een heleboel piraten uiteindelijk ook wel.
2) Het is geen stelen want de maker raakt niets kwijt.
Ook gedeeltelijk mee eens. Je steelt immers niks, maar je maakt wel een kopie van de bron. Wat het wel illegaal maakt, is als de kopie zonder toestemming is gedaan. Dit valt niet onder stelen, maar puur onder schending, meer niet.
3) De maker heeft genoeg andere mogelijkheden om ermee te verdienen, reclame erin verwerken en merchandising eromheen enzo.
Dat is hoe vooral in het verleden de Free2Play games waren, maar tegenwoordig zijn microtransacties hot, dus zijn ze vooral daarover geschakeld.
4) Door het verspreiden van kopieen aan vrienden en familie krijgt de maker grotere bekendheid en leren meer mensen zijn product kennen. Dat is toch zeker ook flink wat waard!
Heeft ook weer een kern van waarheid in, zolang het binnen de familie blijft natuurlijk. Als je het aan jan en alleman gaat geven, dan wordt het weer een ander verhaal.

Ik maak ook vaak genoeg dingen in mijn vrije tijd, en verdien er ook niet zo veel aan, of at all. Maar als je veel tijd en energie ergens in hebt gestoken, dan zou je wel een vergoeding willen verwachten, maar je moet idd niet raar opkijken als mensen het downloaden, om even te kijken of het echt kudt is.
Geef even een voorbeeld: Morrowind en Skyrim. Mensen konden die schijfjes makkelijk kraken, zat amper tot geen beveiliging op, maar mensen kochten de game in masses. Dat komt omdat Skyrim gewoon best wel een toffe game is, ondanks alle bugs.

[Reactie gewijzigd door Power2All op 22 juli 2024 15:42]

Is iOS juist niet hèt voorbeeld van dat hele generaties het niet erg vinden om te betalen voor software?
Of juist dat ze het alleen doen wanneer het niet anders kan. Op Android hoef je alleen maar te zoeken op "[app naam] + apk" en je hebt 'm al gratis. Notebene via Google's eigen zoekmachine.

Daar kan zelfs €2 niet tegenop concurreren.

[Reactie gewijzigd door Wolfos op 22 juli 2024 15:42]

Jij zegt het. Intussen heeft Google de afgelopen 5 jaar 127 miljard dollar omzet met Google Play behaald, bijna 40 miljard dollar vorig jaar alleen al.
En hoeveel daarvan zijn "gratis" apps?
Apple wil dat je voor rereleases betaald en niet dat je gratis oude games via dosbox draait. Daar gaat het ze om.
Wat een bullshit weer, Dos games zijn wel 25+ jaar oud, de generatie wat daar animo voor heeft is niet zo kieskeurig en weet ook wel dat niet alles 100% kan werken.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 15:42]

Daar gaat Apple's uitspraak dan ook helemaal niet over. Het gaat om apps die zelf willekeurige code kunnen uitvoeren. Dat is natuurlijk het doel van een emulator, maar als veiligheidsregel voor apps helemaal niet zo'n gek idee.
Op zich heb je gelijk alleen wordt deze regel zeer inconsequent gehandhaafd. Er zijn heel veel apps die intern b.v. een Lua interpreter hebben, wat eigenlijk niet mag.
Intern een interpreter hebben is niet het probleem.

Waar de code vandaan komt die de interpreter gaat uitvoeren, dát is het probleem. Als dit in de applicatie zit ingebouwd, prima. Als je dit extern via een file transfer kunt aanbieden, is er wel een probleem.
Dat is wel degelijk een probleem. Waarom denk je anders dat er geen echte browsers op iOS zijn behalve Safari?
Volgens mij heb ik ook Chrome en Firefox.
En die gebruiken de iOS renderer op basis van Safari, niet hun eigen engines.
Nee die gebruiken webkit. Geen Safari of “Safari renderer”.
Excuseer dat ik de naam niet goed gebruik. Wat ik zeg klopt echter nog steeds, ze gebruiken de iOS renderer en niet hun eigen.
Volgens mij heb je Chrofari en Safox, want ze gebruiken beiden Safari als engine.
React Native apps en ook Apple's eigen TVOS downloaden anders gewoon scripts en assets vanaf het internet, zodat ze niet de hele app hoeven te updaten.
Dus als je het zo stelt, dan overtreedt Apple hun eigen regels? :+
RIP browsers I guess
Geen gek idee nee, maar het maakt een hoop dingen onmogelijk.

Je kan een smartphone zo dichttimmeren dat het super veilig is maar dan kom je op een Nokia 3210 uit. Ook niet echt de bedoeling denk ik. Laat dan de gebruiker de keuze kunnen maken.

Om deze reden gebruik ik ook geen iOS overigens. Ik wil meer kunnen kiezen dan Apple biedt.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:42]

Dus….. je hebt keuze?

Ik ben ook blij met de mogelijkheid om voor een afgeschermd, gecontroleerd ecosysteem met behoorlijk wat consistentie te kunnen kiezen.

Als Apple verplicht word om alles toe te laten en open te gooien wordt die keuze mij ontnomen en dat wil ik niet. Ik heb geen tijd en zin om alles zelf uit te zoeken.
Het is niet wel of niet afschermen voor het hele IOS. Het is wel of niet afschermen voor iedere gebruiker apart. Als je de beveiliging zelf mag uitzetten/instellem als gebruiker is er geen probleem. Standaard alles afschermen totdat de gebruiker expliciet aangeeft dat hij of zij wat anders wenst mag ook.

Als Apple dingen opengooit doen ze dat voor gebruikers die daarmee akkoord gaan, niet voor jou.
Ik zou willen dat ze het zelfde doen als met macOS. By default is die ook dichtgetimmerd, maar je kunt als gebruiker/admin die deuren open zetten als je wilt via de eigen instellingen van het OS zelf.
Dan gebruik je dus ook geen macOS? Want daar kun je diezelfde beveiliging uitzetten/omzeilen.
Beetje jammer dat ze deze app dus al 7 jaar in de appstore hadden staan. Kennen ze in Amerika ook niet gewoonterecht?
Wat is een “gewoonterecht”? Als ik al 7 jaar niet betaal op een betaalde parkeerplaats, mag de politie me dan na 7 jaar geen boete geven omdat ik uit gewoonte ‘gratis’ parkeer? En als ik al 7 jaar Symbian gebruik om in de winkel te betalen, mag ik dan eisen dat de winkel in kwestie Symbian blijft ondersteunen?

Gewoonterecht, het moet toch niet gekker worden 8)7

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 15:42]

De politie mag je best een boete geven op dat moment voor die overtreding, maar jij kunt naar de rechter stappen en deze ongedaan laten maken op basis van gewoonterecht. Zo is er bijv. ook een eis voor een trademark dat je die als eigenaar actief beschermt (anders vervalt deze). En 7 jaar in de appstore van 's werelds grootste appstore fabrikant staan zonder dat je opvalt betekent, wat mij betreft, dat het recht om die app te schrappen verloren hebt.
Ik verwacht dat je die rechtszaak verliest.
Uit jouw linkje:
Een belangrijk kenmerk van gewoonterecht is dat het van generatie op generatie mondeling wordt doorgegeven.
Jij zal niet hard kunnen maken dat jij al 7 jaar van de politie de toezegging hebt dat je daar mag parkeren.
(Je hebt enkel het geluk gehad dat je geen controle hebt gehad).

Als je het gelinkt artikel van MacRumors bekijkt, dan stonden ze niet jaren in de App Store zonder op te vallen. Er zijn meermalen clashes geweest.
Ach, alles gaat sneller in de digitale wereld. Wellicht tellen smartphone generaties ook :+
Correct, is een terecht bezwaar
Daar wordt achter geschuilt inderdaad, Apple ziet het als een bedreiging.
Wat een bullshit weer, Dos games zijn wel 25+ jaar oud, de generatie wat daar animo to heeft is niet zo kieskeurig.
Wat heeft dat er mee te maken? Het gaat erom dat Apple niet wil dat "apps [....] uitvoerbare code [...] installeren". Of je het daar mee eens bent is vers twee, en of het terecht is is vers drie. Maar als je voorwaarden schendt en je wordt dan op je vingers getikt moet je niet huilie doen.

[Reactie gewijzigd door RobIII op 22 juli 2024 15:42]

Een app als Apple Shortcuts importeert ook uitvoerbare code van andere mensen via het internet. Idem een game als roblox of minecraft.

Edit: en specifieker, een app als iSH draait emulated alpine linux inclusief apk repositories (wel mirrors, maar toch). Die is na wat discussie expliciet toegestaan door Apple. De crux lijkt hem dus te liggen dat mensen wel code mogen importeren via de developer maar niet direct van henzelf.

[Reactie gewijzigd door WoutervOorschot op 22 juli 2024 15:42]

Apple Shortcuts is gewoon een configuratie, geen uitvoerbare code?
Als de configuratie zegt: "doe dit" is het toch uitvoerbaar?
Vanuit configuratie/scripts/macro's kun je niet bij (veel) dieper gelegen OS fucties (hacks daargelaten).

Dergelijke zaken draaien allemaal in een sanbox (of equivalent) waarin de mogelijkheden zwaar beperkt zijn.

[Reactie gewijzigd door RobIII op 22 juli 2024 15:42]

Alle 3rd party apps draaien sowieso in een sandbox. https://support.apple.com...ndboxing-apd826604be4/web

Dit is de hele reden waarom je iTunes moet gebruiken om uberhaupt deze files in dit programma zichtbaar te kunnen maken. Alles wat de emulator run blijft dan per definitie ook binnen die sandbox.
.oisyn Moderator Devschuur® @RobIII23 juli 2021 12:30
Dat standpunt gaat natuurlijk uitermate op voor een DOS emulator. Een oude DOS applicatie zal moeilijk functionaliteit van iOS kunnen aanspreken
Ik weet er het fijne niet van maar als de host (emulator) native draait en de client (emulated software) die rechten "inherit" kan ik me wel voorstellen dat je met vieze low-level truukjes op memory oid enge dingen kan doen.
Volgens die logica staan je binaries dus in /etc? Heb je execute bit op 1 staan op de inhoud daarvan?
Mijn /etc/init.d staat vol scripts... wat ik bedoel is dat je moet oppassen met aannemen dat je code en data twee verschillende dingen zijn. Zeker als je te maken hebt met scripting engines die veel functionaliteit ontsluiten.
Je kan een configuratie maken die JavaScript uitvoert. Het importeren van shortcuts van anderen is gedoe, je moet eerst zelf een werkende shortcut hebben gemaakt en een checkbox aanvinken voordat je shortcuts mag importeren van "Untrusted Shortcuts". Zie https://support.apple.com/en-us/HT210628

[Reactie gewijzigd door Blaise op 22 juli 2024 15:42]

Wat is het verschil? In beide gevallen kun je logica programmeren. Of je nu "if(a) { b }" schrijft, of een 'blok' toevoegt van het type 'if' en dan definieert wat er moet gebeuren... dat is gewoon beide 'uitvoerbare code'.
Het is bekend dat het app approval proces een crapshoot is. Echter helpt het ook niet dat elke willekeurige Apple fanboi/hater/fencesitter wel even een waarde oordeel vellen op basis van incomplete informatie...

Ik heb al heel lang iDos op m'n iPhone staan en het staat me bij dat ze al eens eerder in de clinche met Apple hebben gelegen over de de voorwaarden. (Tweakers.net en Google gaan over hun nek als ik zoek op iDos) Ze wisten dus donders goed dat dit tegen de voorwaarden was, zeker als die functionaliteit er pas in 2020 is toegevoegd.

Soms heb ik het idee dat developers die al hebben gecashed met hun apps dergelijke ongein uithalen om de software maar niet meer te hoeven supporten en zo Apple de 'schuld' kunnen geven... ;-)
.oisyn Moderator Devschuur® @WoutervOorschot23 juli 2021 12:38
Idem een game als roblox of minecraft.
Minecraft (de Bedrock editie althans) runt geen extern uitvoerbare code. Mods bestaan uit grafische resources en/of behaviors. Dat laatste zou je kunnen beschouwen als "programmacode", maar het is eigenlijk gewoon een uitgebreide manier van configureren. Maar goed, het grensgebied is natuurlijk een beetje vaag. Wanneer is iets wel programmacode en wanneer niet. Evenzo kun je stellen dat de assembly die door de DOS emulator wordt ingelezen ook gewoon configuratiestappen zijn voor de te emuleren x86 processor. Wanneer is iets dan programmacode? Als het Turing-complete is?

Met Roblox daarentegen heb je een zeer valide punt. Roblox games bestaan oa uit lokaal uitvoerbare code, en dat gaat regelrecht in tegen punt 2.5.2:
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.

[Reactie gewijzigd door .oisyn op 22 juli 2024 15:42]

Even out-of-the-(dos)box gedacht: dan kun je toch DOSBox draaien binnen iSH? Of vergeet ik nu iets?
Wat Apple zélf doet hoeft natuurlijk niet aan hun voorwaarden te voldoen (al is dat wel zo netjes). En die andere weet ik niet, maar dat zal allicht sandboxed zijn of op een andere manier aan de voorwaarden voldoen. Of ze hebben een deal gesloten, dat kan ook nog :P

En anders jailbreak je je foon maar of ga je naar Android ;)

[Reactie gewijzigd door RobIII op 22 juli 2024 15:42]

Wat Apple zélf doet hoeft natuurlijk niet aan hun voorwaarden te voldoen (al is dat wel zo netjes).
Dat lijkt me nogal stug. Mag de politie dan ook ineens 160 op de N40 rijden? (even noodsituaties buiten beschouwing gelaten) Of mogen leden van de Eerste Kamer vergunningsloos met een wapen rondlopen?

Nee, ook degenen die de regels maken en/of handhaven dienen zich gewoon aan de regels te houden, al is het maar om het goede voorbeeld te geven. Dat geldt dus ook voor Apple.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 15:42]

Wat een onzin. Apple máákt de regels en als ze zich daar zelf niet aan houden is dat hun goed recht. Hun hardware, hun software, hun store, hun ecosysteem. Hun alles.
Dus de Eerste Kamer mag de regels die ze gemaakt hebben ook negeren. Helder.
Hoe is dat is he-mels-naam een vergelijk :? We hebben het hier niet over een regering maar over een commercieel bedrijf 8)7

En daarbij: als het de Eerste Kamer zou believen dan kunnen ze inderdaad best een uitzondering opnemen. Of de bevolking het pikt is vers twee.

[Reactie gewijzigd door RobIII op 22 juli 2024 15:42]

Dat word weer gedeeltelijk recht gebreid met onzin dat Roblox alles behalve iets met games te maken heeft..

[Reactie gewijzigd door DutchKevv op 22 juli 2024 15:42]

Er zijn in de praktijk genoeg apps die code uitvoeren / downloaden, en dat vindt Apple prima volgens hun richtlijnen. Er zijn bijvoorbeeld React Native apps die javascript bundles bevatten en worden uitgevoerd om de interface weer te geven. Delen van de Facebook app zoals de Marketplace maakt hier bijvoorbeeld gebruik van.

Het gaat er volgens mij voornamelijk om dat Apple niet wil dat apps inhoudelijk compleet anders wordt door het uitvoeren van code. In dit geval gaat het natuurlijk om een emulator maar het komt er wel op neer dat je compleet verschillende games / apps / ervaringen hebt door het uitvoeren van verschillende binaries / images.

Waarom Apple het nu ineens weigert? Random. Het is mij vaak genoeg overkomen dat een feature in die al in eerdere versies aanwezig was pas in een veel latere release door Apple afgekeurd wordt. Het lijkt soms wel alsof ze telkens een beperkte set aan eisen valideren bij elke update. Er is geen vinger op te krijgen.
Het lijkt soms wel alsof ze telkens een beperkte set aan eisen valideren bij elke update.
Of hun detectiemethodes veranderen/verbeteren, voortschrijdend inzicht enz. Zou dat niet een véél meer voor de hand liggende reden zijn anders dan "Apple heeft random de pik op me!" :?
Er zijn bijvoorbeeld React Native apps die javascript bundles bevatten en worden uitgevoerd om de interface weer te geven.
En kun je vanuit die code dan ook bij dieper gelegen OS functies? I bet not ;) En anders is dat vast opgevangen in een uitzondering of...

[Reactie gewijzigd door RobIII op 22 juli 2024 15:42]

Een significant deel van de apps in de App Store is met React Native gebouwd. Daarbij draait JavaScript in een een eigen runtime, rendered UI naar native (geen html) en is het vervolgens mogelijk om over-the-air updates te doen buitenom de App Store. Dat mag dus wel :?
Het is niet zo makkelijk om hier een goed antwoord op te geven. Microsoft heeft een stuk geschreven over react-native-code-push, en quote daarbij de Apple Developer Program License Agreement.
Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.
Zo lang je niet je core-functionaliteit aanpast, zou het moeten mogen. Dit verklaart dan ook waarom Apple de dos-emulator niet toestaat.

Overigens zijn er wel apps geweerd omdat Apple ontdekte dat er een auto-update mechanisme in zat waarmee de app geüpdated kon worden, dus het blijft een beetje onduidelijk.
Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with App Store Review Guideline 2.5.2 19 and section 3.3.2 of the Apple Developer Program License Agreement 8.
Een ontwikkelaar van Expo had het volgende erover te zeggen (in 2019):
As long as OTA updates aren’t used for malicious or deceitful changes to an application, they fall within the guidelines. The rejections that we’ve heard of Expo developers getting regarding guideline 2.5.2 often are one-off instances that end up being the result something else. We recently got a report of this happening but haven’t heard back from the reporter about what the rejection stated.

With that said, we have 1000s of iOS apps being built and numerous Expo apps that have successfully been submitted and updated on the App Store that make use of OTA updates.
Zo lang je niet je core-functionaliteit aanpast, zou het moeten mogen. Dit verklaart dan ook waarom Apple de dos-emulator niet toestaat
De core-functionaliteit is toch het emuleren van DOS?
Lastig om te zeggen, ben ook geen expert. Je kan zeggen dat je:

- zonder externe download, niet kan gamen
- met externe download, wel kan gamen

Dat kan Apple zien als een significant verschil in functionaliteit.

Volgens mij laten ze andere game-emulators ook niet toe, toch?

edit:
Ik ben 't er verder niet mee eens, maar ik denk dat ze zoiets als argument gebruiken.
Ik schrijf/maak/handhaaf de regels van Apple niet maar als jij het zegt: klaarblijkelijk dan. Er zal allicht een verschil in zitten :)
Mee eens, maar het zou Apple wel sieren er niet 7 jaar na eerste publicatie van de app pas achter te komen en het te verbieden als ze zo hoog van de toren blazen over hun veilige ecosysteem (waar ik zelf overigens ook met veel plezier gebruik van maak).
Als Apple in 2014 had gezegd: nee mag niet, dan had je een punt. Nu is het een bestaande app (al 7 jaar in de appstore) gaan verbieden. Dat slaat als een tang op een varken.
Niet alle DOS games zijn zo oud. Deze is uit 2020: https://voxel.itch.io/slipspeed
Ik snap het niet. Die uitvoerbare code zal dan toch bestaan uit DOS executables? Dat kan toch voor iOS niet schadelijk zijn? Wie weet hoe dit precies zit?
Omdat dit de monopoliepositie van de Appstore onderuit haalt. Je kunt dan overal apps vandaan gaan halen, vermomd als DOS executable, die onder de duiven van Apple (en andere developers op de Appstore) gaan schieten.
Dat is ook de reden dat ze safari beperkt houden qua webapps want dan stort het verdienmodel ook in elkaar.
Wat let je om een nieuwe DOS applicatie te maken die specifiek iOS probeert om de tuin te leiden? Het zal ook vast niet gaan om de games van 25 jaar geleden maar om het feit dat je willekeurige executable code host waar Apple's kwaliteitscontrole (en andere "evil controles") geen zicht op heeft.
Oke, dat is een goed punt. Maar kunnen andere bestanden, die officieel geen executables zijn, dit ook niet doen? Denk bijvoorbeeld aan macro's in Excel files, of Javascript in browsers.
.oisyn Moderator Devschuur® @rijnsoft23 juli 2021 14:08
Denk bijvoorbeeld aan macro's in Excel files
Die doen het niet op iOS.
Javascript in browsers
JS kan maar uitgevoerd door 1 browser: Safari.

[Reactie gewijzigd door .oisyn op 22 juli 2024 15:42]

Macro's draaien typisch ook in een sandbox, evenals JS.
Alle iOS apps draaien in een sandbox - by design-, dat argument geldt dus ook voor iDOS en andere emulators.
Mag dit soort gedrag straks nog wel met right to repair?
Dit gaat over SOFTware , not REpair ;)
Dit staat los van Right to Repair lijkt mij, aangezien dat puur gaat over de mogelijkheid voor de eindgebruiker om een device te (laten) repararen.
Hoe doet het feit dat ze een app weren afbreuk aan een eventueel recht een apparaat te (laten) repareren?
Omdat het niet meer werkt zoals je verwachtte en zoals het al tijden gedaan heeft... Het is misschien wat vergezocht maar ik probeer de mogelijkheden te verkennen/peilen.
Lijkt mij iets te vergezocht eerlijk gezegd, ik denk dat right to repair veel meer op hardware dan software gericht gaat zijn.

Daarnaast de werking van je iPhone is nog hetzelfde en Apple heeft altijd gezegd dat dit soort apps niet mochten dus er valt volgens mij niets te herstellen.
Ik snap deze superconservatieve beweegreden als argument om virussen en ongewenste appgedrag op iPhones te verminderen; het downloaden en uitvoeren van externe code is inmiddels zowel een manier om andere policies te omzeilen alswel een mogelijkheid voor virussen om hun payload te downloaden. Toch is het eigenlijk wel een erg rigoreuze regel.

Ik vraag me af hoe Apple dan omgaat met progressive web apps en zelfs browsers en websites; die downloaden immers ook uitvoerbare code (javascript) van externe bronnen die de werking van de app aanpassen. Browser-specifiek is het natuurlijk nóg weer een ander verhaal, omdat alle iBrowsers op basis van webkit moeten draaien. Een ideetje voor een achtergrondartikel (plus?) om dieper in te gaan op Apple en het modereren, gatekeepen en verwijderen van diverse "goedwillende" applicaties door de jaren heen? Eventueel met een uitstapje naar door de staat gewenste censuur... (door bijvoorbeeld China)
Ik vraag me af hoe Apple dan omgaat met progressive web apps en zelfs browsers en websites; die downloaden immers ook uitvoerbare code (javascript) van externe bronnen die de werking van de app aanpassen.
In een zwaar dichtgetimmerde sandbox...
Eigenlijk zou elke app gewoon gesandboxed moeten zijn. Dat is pas goed voor de beveiliging.
Alle niet-Apple apps zijn dat al.
In een zwaar dichtgetimmerde sandbox...
Een DOS-emulator kan toch ook zwaar dichtgetimmerd zijn? Als de emulator zich netjes houdt aan de grenzen van zijn app permissies dan is het niet meer/minder veilig als iedere applicatie.
RobIII Moderator GoT @ari323 juli 2021 12:06
Een DOS-emulator kan toch ook zwaar dichtgetimmerd zijn?
Ja, en :? Dat het kán wil niet zeggen dat het zo ís? Dus misschien moet Chaoji Li even terug naar de tekentafel?
Goed punt om te maken, alleen maak je precies het tegenovergestelde punt. Je browser is namelijk een van de grootste beveiligingsrisico op je telefoon. De teams die Safari ontwikkelen zijn ietsjepietsje groter en serieuzer dan die van een DOS emulator app.

Het probleem met het inladen van code is dat het veel moeilijker is om zeker te weten dat de app dit vellig uitvoert. Het is heel moeilijk (lees onhaalbaar) om te zien wat een interpreter doet. Het kan zomaar zijn dat het een private API aanspreekt of het complete gedrag van de app beïnvloed. Dat is natuurlijk ook precies het doel van een DOS emulator.
En webassemblies zijn ook direct emulatie van code die door je browser wordt uitgevoerd.
Webassembly is gewoon een efficientere vorm van Javascript code en draait in dezelfde browser sandbox.
Nee, het is niet efficientere Javascript. Misschien ben je in de war met asm.js, waarbij er source-2-source conversie plaatsvindt met emscripten.
Webassembly is een binary format, met een eigen runtime.
Webassembly gebruikt delen van de Javascript runtime. Omdat het bytecode is kan het Javascript specifieke deel 'overgeslagen' worden en zijn bepaalde optimalisaties niet nodig. De machinecode optimalisaties worden, in ieder geval in de V8 runtime, gedeeld met de Javascript JIT.
Ik vraag me af hoe Apple dan omgaat met progressive web apps en zelfs browsers en websites
Dat zijn gewoon webpages in Safari.
Sinds 2020 is het mogelijk gamebestanden te uploaden in iDOS, waaronder via iCloud-opslag, waar Apple nu bezwaar tegen maakt.
Hoe laadde je voor de wijziging in 2020 applicaties? Werden die door iDOS 2 zelf via het internet gedownload of gebundeld?
Ik vermoed dat je ze gewoon zelf op de local storage van je iPad moest zetten.
Ze hadden voor een bepaalde tijd alleen een command line. En de maker verwachtte ook geen goedkeuring, todat hij dat (om een of andere reden) wel kreeg:

https://litchie.com/2020/09/idos2-update
Even een vraagje, als ik hem nu koop in de appstore, komt ie op m'n telefoon en kan ik hem gebruiken, wat gebeurt er dan in de toekomst (nieuwe telefoon, frisse installatie etc) als ik de app opnieuw wil downloaden, is hij dan niet meer te vinden?
Als het goed is wel, je kunt dan via je ‘eerdere aankopen’ de laatste versie weer installeren
Vreemd, het is toch in principe een soort launcher. Wat is daar mis mee?
Die editor lijkt trouwens als twee druppels water op die van Turbo Pascal.

Edit: het is Turbo C, van dezelfde maker.

[Reactie gewijzigd door Alex3 op 22 juli 2024 15:42]

Nou zeg, nooit geweten dat er een editor voor was. We gebruikten destijds altijd DOS edit :/ Dat was eh... uitdagend. Ik kan me nog herinneren dat ik voor het eerst Visual Studio 6 mocht opstarten, tranen in mijn ogen.
Borland had (heeft?) een hele set van compilers en bijbehorende ontwikkelomgevingen... ben met de hele set opgegroeid ;-)
Turbo c is van 1987 en de blauwe dos edtitor kwam een jaartje later.. visual studio 6 is van 1998.... in die twintig jaar die er tussen zit heb je voor niets dos edit gebruikt ;-)
Het is maar 10 jaar tussen 1987 en 1998 ;) Maar ben helemaal met je eens, een beetje developer kende sowieso wel de Borland tools, dat waren toen toch wel hele goede IDE's. Zelf veel gebruik gemaakt van Turbo Basic en Turbo Pascal.
Owja. het voelde 20🤣
Als ik de app nu koop, blijft deze dan staan in mijn aankoopgeschiedenis om later op nieuwe apparaten nog te downloaden?

Gekke vraag misschien, maar als een app niet langer ondersteund wordt op een oudere iOS versie kan je alsnog een oudere versie van die app downloaden als deze in je aankoopgeschiedenis staat. Zelfs als de app gratis is. Dus dan lijkt het me niet onmogelijk dat deze app ook nog binnen te halen is, maar kan er weinig over vinden behalve dat de app wel beschikbaar blijft als je hem al gedownload had (duh).

[Reactie gewijzigd door crazyboy01 op 22 juli 2024 15:42]

[Concurrentie voor monopoliepositie Apple store]
Juist, dit is de echte reden.
En de beste remedie is om alleen hardware + OSen te kopen
waarover jij helemaal (oke grotendeels) de baas bent.

[Reactie gewijzigd door Geekomatic op 22 juli 2024 15:42]

Op dit item kan niet meer gereageerd worden.