[HN Gopher] Apple Updates App Store Guidelines to Permit Game Em...
___________________________________________________________________
Apple Updates App Store Guidelines to Permit Game Emulators, EU
Music App Links
Author : bangonkeyboard
Score : 108 points
Date : 2024-04-05 20:16 UTC (2 hours ago)
(HTM) web link (www.macrumors.com)
(TXT) w3m dump (www.macrumors.com)
| talldayo wrote:
| Better late than never...? Watching this all get walked back is
| kinda surreal, makes you wonder what the _actual_ precedent was
| for keeping them off the App Store in the first place. There
| really shouldn 't be that many hoops to running GBA4iOS on
| hardware you paid for.
| kccqzy wrote:
| The actual reason was that Apple wants to encourage native
| development instead of targeting some other platform and then
| emulating or simulating that on iOS.
|
| At one point they even required all iOS apps to be written in
| only C, C++, Objective-C, Objective-C++, JavaScript and no
| other languages. They walked that back almost immediately.
| withinboredom wrote:
| I vaguely remember this as well, but that wasn't the only
| reason. The other reason was security/ability to review apps.
| If an app can run arbitrary code, then they don't know if it
| contains a virus or something else to escape the sandbox. Or
| something like that. This was all quite a long time ago and
| Google isn't being super helpful in searching for old posts.
| ben_w wrote:
| That rings a bell for me too, FWIW.
| simion314 wrote:
| I bet it is not about the viruses, Apple does a bad job at
| catching malware. They are very concerned if a developer
| might show some link that would educate an apple user that
| they can get discounts outside the App Store so it is clear
| that all was for the money. If you have an emulator and
| then say get some old game from Gog and play it then Apple
| does not get their 15-30% cut, they want you to buy a game
| from their store instead.
| withinboredom wrote:
| Oh, no doubt this is ALL about money. I was just
| recalling the "official" reason.
| Mathnerd314 wrote:
| Here is an example removal (2021):
| https://www.imore.com/apple-going-remove-idos-2-emulator-
| app...
|
| It seems that they considered loading game images as
| "running executable code". So in particular what was banned
| was running code downloaded remotely, meaning any emulator
| that could download game images from the web or load game
| images from the filesystem was banned.
| talldayo wrote:
| Well that's the part that sorta confuses me. There were a lot
| of high-quality emulators that were native to iOS, and
| sideloading them was the only way to use it. There was also
| the same bog-standard port of Retroarch et. al., but
| developers really _did_ put effort into making high quality,
| even Open Source, iOS-native emulation software.
|
| The sinister side of me wants to say that stopping emulation
| forces more users down the IAP/microtransaction feedback loop
| in order to entertain themselves. The rational side of me
| wants to say that _Yoshi 's Cookie_ isn't the _Fortnite_
| killer, but the whole thing feels icky to me nevertheless.
| jwells89 wrote:
| I think they wanted to somewhat replicate what they had on
| macOS, where the best and most popular apps were those built
| by indie/boutique dev houses that cared specifically about
| building great _iOS apps_. Lowest common denominator apps
| that treated iOS as a generic mobile target (and thus,
| ignoring platform conventions and such) were undesired.
|
| I'm not sure that ever could've happened given the popularity
| of iOS, though. Companies like Panic and Omni Group don't
| have the sort of firepower it takes to compete against the
| sheer amount of money poured into marketing by Facebook,
| Google, VC-backed startups, etc.
| modeless wrote:
| Yeah, funny how the threat of actual competition (even crippled
| as it is) promotes user-friendly policy changes. Imagine that.
|
| I think the reason was that Apple didn't want to get sued by
| Nintendo. They use the same locked down platform strategy as
| consoles so it would look bad if they were complicit in
| circumventing other platforms' restrictions. Still a lame
| reason. I definitely expect some litigation related to
| emulators on the app store though.
| doublerabbit wrote:
| So what, we're now back to 2018 when emulators were all the hype?
| Cool.
|
| Err, why am I flagged from this thread? - I mean seriously cool.
| 2018 was the hype when emulators were the thing. It's great to
| see such.
| ben_w wrote:
| 2018? I missed that wave. I seem to remember they were cool in
| the late 2000s or so? Perhaps that was just me...
| amlib wrote:
| i remember emulators really getting popular as a means to
| play the original pokemon games without owning a gameboy back
| in the late 90s...
| Apocryphon wrote:
| Yeah, Bleem! was around since 1999.
| MBCook wrote:
| When was UltraHLE? Like '98?
| oneplane wrote:
| I think it might be around the same time as the RetroPie wave
| when it got much more publicity than the early days around
| 2013, probably somewhere between the release of the Pi 3B and
| Pi 4B (2018-ish?).
|
| Around that time it was mostly N64, SNES, GB, GBA etc. Maybe
| even some PS1, but mostly just titles that were plausibly
| playable on a smaller screen or with lower resource
| consumption. Wouldn't be surprised if it gets attention on
| iOS when there is a larger public mindshare around such a
| topic.
| talldayo wrote:
| That's not even that far back either, GBA4iOS has builds going
| back to 2014. 2018 was the year you could emulate Nintendo
| games... on the Switch:
| https://www.libretro.com/index.php/category/switch/
| thih9 wrote:
| Have any emulator apps been published and approved already?
| internetter wrote:
| App store review isn't that fast
| rezonant wrote:
| We've been waiting since holidays last year for one of our
| updates to be reviewed.
| RedComet wrote:
| The use of "retro" is interesting. Probably intended to exclude
| Switch emulators, but what will the cutoff be?
| goryramsy wrote:
| There are Switch emulators for iOS [0]
|
| [0] https://github.com/emuPlace/Sudachi
| jsheard wrote:
| They may exist, but the implication is they won't be allowed
| on the App Store.
| goryramsy wrote:
| All depending on an ambiguous 'Retro' requirement. Would an
| out of production device be 'retro'? If so, then Switch 2's
| ~2025 upcoming release would retro-ify many games.
|
| I guess we'll see soon based on what passes app review.
| goryramsy wrote:
| Forgot about Folium.
|
| https://folium.emuplace.app/changelogs
| duskwuff wrote:
| Realistically, the cutoff is likely to be "can you point to a
| legitimate source of ROMs". There's enough fan games for some
| older consoles like Atari 2600 or NES that this might be
| possible, but it certainly wouldn't be possible for newer
| consoles like the Switch.
| willis936 wrote:
| It's much easier to get your hands on a switch game and rip
| it with your hacked console (all perfectly legal acts) than
| it is to get a 20 year old artifact.
| ascagnel_ wrote:
| Probably up through the PSX, at least in the US:
|
| - hardware to dump your own cartridges is available and
| doesn't require breaking copy protection (which at that point
| was more around locking out publishers that didn't sign
| license agreements rather than unauthorized duplication), and
| popular older systems are fairly well understood at the
| interconnect level at this point
|
| - PSX games themselves don't use encryption to protect games,
| just some chicanery around CD standards so burners of the era
| wouldn't make unauthorized duplication as much of an issue;
| additionally, the Bleem! case officially recognizes PSX
| emulation as legal
|
| Once you get to the PS2/GameCube/Xbox generation, you start
| to run into systems that include encrypted executables that
| make DMCA-compliant emulators basically impossible.
| withinboredom wrote:
| > They want to use Apple's tools and technologies, distribute on
| the App Store , and benefit from the trust we've built with users
| - and pay Apple nothing for it
|
| This quote smells like a "self-induced problem" since they
| literally require developers to buy or rent their hardware to
| build an app and also (at least, previously) required developers
| to publish on the App Store. If I could build an iPhone app on my
| Windows machine and publish an app from my website, then their
| argument wouldn't make any sense.
| Drakim wrote:
| To me it smells like flat out dishonesty. They are pretending
| the App Store is this premium high quality service that the
| riff-raff wants to get unfair access to, while they have
| actually been fighting tooth, claw, and nail to make any other
| alternative way of getting apps onto the iPhone physically
| impossible. If I wanna make an app for my mom's iPhone, I
| *can't* because Apple is preventing me. All while saying I'm
| trying to take advantage of them by wanting to get my app on
| the App Store. While working hard to make sure I have no other
| options.
|
| It's one small step removed from "stop hitting yourself" logic.
| withinboredom wrote:
| Further, they actively stifle competition on their app store.
| Want to launch an MVP? It's "too similar to other apps in
| this market."
| ben_w wrote:
| While I doubt they're going to be good judges of
| similarity, in the cases where they are correct that it is
| too similar, you don't have the "V" part of "Viable".
|
| > "All happy companies are diferent: each one earns a
| monopoly by solving a unique problem. All failed companies
| are the same: they failed to escape competition"
|
| -- I may be creeped out by the guy himself, but I think
| Peter Thiel is right about that.
| withinboredom wrote:
| Everyone starts in the womb, but very few of us tread the
| same paths.
| ben_w wrote:
| I think the human analogy of an MVP is around when they
| can stand upright and talk, perhaps even a bit later than
| that. Before _birth_ we 're definitely a pre-release; but
| we won't reach product-market fit until whatever our
| culture counts as a coming-of-age ceremony.
| Pfhortune wrote:
| Isn't this just picking winners with more steps?
| ben_w wrote:
| Mild disagree, though I can appreciate the sentiment.
|
| Why do developers want to publish and distribute on the App
| Store?
|
| As a dev myself, my anecdotal answer is: _because I can make
| money doing so_.
|
| Why can I make money doing so? Because Apple built trust with
| the users, and because they developed the tools and
| technologies that made their OS worth paying significantly more
| for similar tech specs.
| withinboredom wrote:
| > I can make money doing so.
|
| Not everyone is interested in making money.
| talldayo wrote:
| If the App Store wasn't the only place to download software
| on iPhone, you'd have more of a point. Instead, it doesn't
| matter what the relationship is between the user and Apple
| since there's only one option anyways. Apple wants to make
| the App Store look like Steam; at best, they're the built-in
| Microsoft store.
| ben_w wrote:
| I remember when the App Store didn't exist, and devs were
| begging for one. And then Apple accidentally discovered it
| was a money printing factory when they got around to it.
|
| Now the MacOS App Store, _that_ vibes with the MS store.
| lapcat wrote:
| > I remember when the App Store didn't exist, and devs
| were begging for one.
|
| They weren't begging for an app store. They were begging
| for third-party native apps. The exact method of
| distribution of third-party apps is a different matter.
|
| From 1977 to 2007, all third-party apps on Apple
| platforms were independently distributed. (Some boxed
| software was sold in retail Apple Stores from 2001, but
| the software was not exclusive to Apple Stores.)
| makeitdouble wrote:
| > Why do developers want to publish and distribute on the App
| Store?
|
| Because it's half of the market, and more depending on who
| you're targeting.
|
| I worked at a shop where we were asked for Blackberry apps
| alongside with iOS and android apps, not because they had
| strong feelings about BlackBerry, but because it was 3% of
| their market share and it was above their cutoff for support.
| staplers wrote:
| because they developed the tools and technologies that made
| their OS
|
| Not quite. They used quite a few FOSS to build their products
| then pulled the ladder up behind them. Remove the app store
| _requirement_ and the market will indicate just how useful
| the app store monopoly is to the end user.
| ben_w wrote:
| > They used quite a few FOSS to build their products then
| pulled the ladder up behind them
|
| Not only but also.
|
| > Remove the app store requirement and the market will
| indicate just how useful the app store monopoly is to the
| end user.
|
| Android suggests: fairly important, even though it could be
| replaced.
| Vespasian wrote:
| I can see where you are coming from and once we have
| meaningful competitive alternatives to the AppStore (so after
| whatever they try in the EU with the platform fee and related
| shenanigans is forced to switch to a sane model) we can make
| a judgement on that.
|
| Right now there is simply no way to know whether people are
| interested in the AppStore itself or simply selling to people
| who own iPhones (which is more likely but I may be wrong).
|
| If I were a high class furniture company and the developer
| building roughly half of the populations' homes could enforce
| that all furniture sold to their customers needs to be vetted
| and distributed by them, of course I would play by their
| rules and even sing their praise.
|
| Apples terms (all of them) are a direct result of their
| ability to stifle any competition on devices their customers
| paid them good money for.
|
| Nothing they do is problematic unless they are able to "my
| way or the highway" their rules on the hardware level.
|
| Apple dug too deeply and greedily and they woke up the
| sleeping regulatory giants which are now changing the rules.
| stale2002 wrote:
| > Because Apple built trust with the users, and because they
| developed the tools and technologies
|
| Hey if those tools and technologies on the Apple App Store
| are so valuable, then Apple has nothing to worry about.
| Developers will just stay on that app store.
|
| If, instead, other competing options are better on some
| metrics than Apple's, then that is a situation where
| developers would move off of the app store.
|
| It seems like we will find out how valuable that app store
| really is soon, won't we?
| benced wrote:
| Apple has this exactly backwards. Their platforms have value
| because of developers. There's a reason Apple added an App
| Store after the app-less first year of the iPhone.
|
| How many people would switch to android, even if they like
| apple's design better, if Apple had no apps? It's just a
| farcical claim on their part.
| pininja wrote:
| Very excited about this! But I've also been impatient and started
| using Eclipse for all of my Gameboy emulation over the last
| year.. it a PWA and uses local storage for game saves.
| https://eclipseemu.me/
| pininja wrote:
| I've also enjoyed using desmume for DS emulation
| https://github.com/44670/desmume-wasm
| speps wrote:
| What's a revoke? Why is it a problem?
| rezonant wrote:
| Guessing here, but I suspect they are referring to the
| revocation of the enterprise signing certificates used by
| gray-market iOS app stores, since native app emulators could
| only be distributed that way until now.
|
| It's whack-a-mole- the stores sign their executables with a
| new certificate, Apple finds out about it, revokes the
| certificate. When that happens, I imagine the software signed
| by that certificate will no longer run on the devices the
| software was installed to.
| pininja wrote:
| I assume they're referring to when the App Store revoked
| everyone's emulator apps. For Apple to break these they'd
| probably need to remove standard web APIs.
| Pfhortune wrote:
| When you load an app on your own iOS device with a free
| developer account, that app will fail to open (as in be
| revoked) after seven days unless you refresh it from a Mac
| (or Windows system with AltStore or similar).
| criddell wrote:
| A web app game emulator? That would probably give you the
| authentic Sega Game Gear experience where your batteries only
| last an hour.
| Pfhortune wrote:
| That's a very negative take, one that disparages the hard
| work of vast swaths of people that not only work to optimize
| WASM in browser engines but also emulator developers.
|
| Likely the small payload/resource-demands of a Gamegear ROM +
| retroarch core are far lighter than most modern websites.
| Your battery life would probably be shorter visiting a random
| ad-filled news website in your browser.
| talldayo wrote:
| Don't give Apple any more ideas, we're a mere 3 antitrust
| suits away from Apps coming in region-locked cartridges.
| voytec wrote:
| Apple has been user-hostile on all possible fronts in their
| efforts to enforce renting model over media ownership.
|
| Some 10 years back iTunes had an option to stream or share media
| over network. It was cool to stuff iMac's 3TB HDD with audio CD
| rips and have all this music available on an iPhone or any other
| iDevice connected to the same local network. I had a VPN
| connection from iPhone to home network and all CD rips available
| anywhere.
|
| To avoid confusion: I'm talking about iTunes-specific
| functionality, not media files sharing. When iTunes was opened on
| an iMac, all iDevices in LAN automatically had all the media
| available through local iTunes apps. And then they "renamed"
| iTunes to Music...
|
| But even during the iTunes era they made it artificially
| difficult to own own media. One would think (or maybe I was
| delusional?) that media library fully synced from desktop iTunes
| to iPhone iTunes serves as kind of a backup. Nope - turns out
| that when desktop disk dies, one can't sync media from iPhone to
| the new desktop disk. Desktop iTunes was happy to suggest wiping
| iPhone media as a sync method.
| oneplane wrote:
| iTunes Home Sharing and RAOP are still present and still work
| fine. Not sure what makes it not work for you (except the VPN
| connection which isn't allowed, Home Sharing is only for a
| single local subnet, those were the rules from the start as can
| be expected with the RIAA etc.).
|
| As for owning media, that was pretty easy, got a bit harder for
| a while and then got easy again. You can get everything you buy
| with no DRM and play it wherever you want for as long as you
| want. There are some limitations with iTunes Match AFAIK
| because again, recording industry/labels said no.
| WWLink wrote:
| IIRC you actually could copy from the phone or ipod back to the
| computer but you had to turn off automatic sync first.
| pipeline_peak wrote:
| Steve Jobs announcing PlayStation emulator at MacWorld
|
| https://youtu.be/3OqMcqRI-xA?si=nUkGn6vLrLLMiGOP
| Wowfunhappy wrote:
| This is really cool.
|
| However, I think an underrated difference between then and now
| is that you could physically put a commercial Playstation disc
| into a standard CD drive and read it, no console hacking
| required.
| ascagnel_ wrote:
| It's trivially easy to take that same PSX disc, make an image
| of it, and load that into an emulator today.
| D13Fd wrote:
| The difference is that the PSX disc had some semblance of
| DRM or at least indicated ownership. Most ROMs are just
| copied.
| pipeline_peak wrote:
| That standard usage is part of what killed the Dreamcast.
| Just burn an iso of Sonic and throw it in.
| rezonant wrote:
| Interestingly, The Dreamcast's GD-ROM format was
| nonstandard enough to _not_ be copyable with a normal CD
| burner, at least at first. They used CAV + cutting the disk
| speed in half in order to write more data (up to 1.2GB).
|
| https://en.wikipedia.org/wiki/GD-ROM
|
| I think what you are referring to is the fact that the
| Dreamcast _itself_ didn 't only read from GD-ROM- it was
| perfectly happy to execute code from a CD-ROM via the MIL-
| CD format.
|
| > The "foot in the door" came from a seemingly obscure
| capability of the Dreamcast to boot not from a GD-ROM but
| from a CD-ROM. Originally intended to add multimedia
| functions to music CDs, the functionality called "MIL-CD"
| was never used much, accounting for a mere seven karaoke
| applications. [1]
|
| Which meant if you were able to acquire a GD-ROM image, and
| you could repack it into the CD-ROM's max capacity of some
| 650MB, then you could burn it to disc and play it without
| any modification of your Dreamcast, at least once the other
| protections were defeated.
|
| For games that actually utilized more than a CD's worth of
| data, usually pirates would recompress or remove images,
| video files and other assets to save space. So that copy of
| Sonic might not behave exactly the same as a genuine copy,
| simply by the necessity of the format (not that I know if
| Sonic required this sort of rework).
|
| Fascinating post from Fabien Sanglard for this:
|
| [1] https://fabiensanglard.net/dreamcast_hacking/
| crooked-v wrote:
| I have to wonder if behind the scenes there was any push here
| from companies that put out licensed emulation collections. For
| example, there are a ton of different SEGA collections that are
| nice GUIs around various ROMs, where doing a native port would
| both be a ton of work and kind of defeat the point of trying to
| faithfully carry across the original with exactly the same
| quirks.
| OatmealDome wrote:
| Notably, Apple still does not allow non web browsing apps to use
| JIT recompilers. This precludes emulators for 6th generation and
| newer consoles (GameCube, etc) from running on the platform even
| with this guideline change.
|
| I submitted a DMA interoperability request for JIT recompilers,
| but Apple denied it on the grounds that it doesn't fall under
| Article 6(7) for "multiple reasons", including that JIT is only
| used by web browsers on iOS.
| VHRanger wrote:
| Luckily for us both the Nintendo switch and the iPhone run
| ARM64, so you don't need a JIT to run yuzu/ryujinx on a phone!
|
| The bad news is that yuzus team is disbanded and never got the
| moltenVK backend done. And Ryujinx never got theirs to work on
| a phone.
| apatheticonion wrote:
| I'm not an expert in emulation but I am curious if one could
| recompile ROMs AOT such that JIT is not required by the
| emulator?
|
| Say, statically recompile the ROM on your PC then move the
| emulator-specific binary to the iOS device.
|
| Would such an approach be permissible by Apple? Is it possible
| to do so while sharing the source code for the JIT layer?
|
| I suppose the binary format must itself be natively compatible
| by iOS otherwise you'd need to have a JIT layer for your binary
| format - right?
| wmf wrote:
| IIRC Apple also doesn't allow apps to load binary code at
| runtime. Redistributing derivatives of ROMs also sounds like
| a copyright problem.
| apatheticonion wrote:
| Could you recompile a ROM and embed it with a universal
| "emulator" game engine? (in the same way the OpenGoal
| project that recompiled Jak)
|
| I guess that would be illegal because you'd then need to
| distribute the game code.
|
| Perhaps a toolkit that allows users to compile the
| emulator+rom themselves?
|
| But then I guess Apple doesn't let users run their own
| unsigned binaries so that's not possible :/
| danielheath wrote:
| You could do Rosetta style conversion up front of the
| complete binary to get around the JIT ban, but that's still
| loading code at runtime.
| avianlyric wrote:
| Historically the justification for limiting the use of JIT
| compilers is for security reasons, which does actually stack
| up.
|
| JIT compilers are one of few use cases where an application
| absolutely needs the ability to write data to memory, mark
| that memory region as executable, and then execute the op
| codes in that memory region. On iOS, other than Safari, no
| application, either built in or installed via the App Store
| is allowed to change memory permissions from writable to
| executable, and that acts as a cornerstone in iOS application
| sandboxing.
|
| Now there's perfectly good argument that the security
| argument doesn't really stack up anymore, given that
| sandboxing technologies have progressed a lot, and it should
| be possible to properly sandbox a JIT compiler or similar.
| But there's no denying the fact that removing the ability for
| an application to execute arbitrary created op codes is a
| very good way to completely eradication a huge surface area
| for exploits. Especially when such restrictions are paired
| with static scanning of binaries before signing (which
| happens when any binary is produced for iOS, via Apples
| signing service).
|
| All of that is to say, there is a possible world where ROM
| are transpiled for iOS devices (using something like
| Rosetta), and loaded as signed binaries via emulation
| wrappers. But at point you're basically having to create your
| own App Store, and sign a new app for each transpiled ROM.
|
| In short, it doesn't seem likely we'll see JIT powered
| emulators on iOS anytime soon, and, at least in this specific
| instance, Apple has a legitimate security reason for
| restricting their usage.
| layer8 wrote:
| You could write a web browser that supports ROMs as script
| source. <script type="application/snes"
| src="..."/>
|
| ;)
| pridkett wrote:
| Some of us remember back in 1999 when Steve Jobs announced that
| Connectix, a PSX emulator was coming to Macs. Different times,
| man. Luckily, YouTube doesn't forget.
|
| https://youtu.be/3OqMcqRI-xA?si=lC2tbRWS-2UGe_8G
___________________________________________________________________
(page generated 2024-04-05 23:00 UTC)