Hacker News new | past | comments | ask | show | jobs | submit login
Apple Updates App Store Guidelines to Permit Game Emulators, EU Music App Links (macrumors.com)
210 points by bangonkeyboard 11 months ago | hide | past | favorite | 136 comments



The emulator change is a minor rule change about bundling and is not what many of the reactions to the change think.

What people seem to think this means: Open-ended retro game emulators like Snes9x and Dolphin are now allowed. (I don't think this is correct.)

What the change is actually doing: If you are the licensed publisher of a retro game collection, you can now offer them in one app (including perhaps downloading additional games added to the collection later) instead of splitting them into individual apps. Each game must be individually vouched for.[1]

What is not changing: "Emulators" have long been allowed if the emulated code is bundled with the app and it is officially licensed.

[1] https://developer.apple.com/app-store/review/guidelines/

"4.7 [...] You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws. [...]"

and

"4.7.4 You must provide an index of software and metadata available in your app. It must include universal links that lead to all of the software offered in your app."


> What the change is actually doing: If you are the licensed publisher of a retro game collection, you can now offer them in one app (including perhaps downloading additional games added to the collection later) instead of splitting them into individual apps.

How is this different than the one-app retro games collections that Apple has always allowed?

(1) https://toucharcade.com/2011/04/06/atari-brings-100-retro-ti... (2) https://www.engadget.com/2012-02-24-midway-arcade-brings-jou... (3) https://www.theverge.com/2017/6/21/15845580/sega-forever-ret...


I think mainly the ability to download additional games, and more specifically, games emulated from a different platform rather than game content written as HTML/JavaScript.

I may be wrong about the bundling in terms of the collection, but I still think this is more about Apple's general stance on "stores within an app", and the rule change is folding retro game emulators in as another exception to that, and not a change primarily about emulator allowability in general.


Based on the release of multiple emulators in the App Store in the past few days (including Delta which looks like it is here to stay), it looks like I got this wrong. My original comment made sense to me based on my reading of the rules, but it looks like they really are allowing open-ended emulators that can load ROMs from anywhere.


Interestingly outside of games and consoles there are “emulators” that run classic HP calculators in the store. They emulate the HP Nut processor which runs small ROM dumps.


Given the policy, I'm still really unclear about how ScummVM was allowed into the iOS app store. Maybe it was a mistake, but it's been up there for months.

There's no conceptual difference between interpreting SCUMM bytecode and interpreting 65816 machine code.


It’s a business difference, not a conceptual one. No one cares if you want to fire up Secret of Monkey Island on your iPad. One company in particular really does care if you want to play Super Mario World on your iPhone. That’s the difference.


My knee jerk reaction is to be disappointed by this, but I had an NES emulator on my first gen jailbroken iPhone back in 2007 or 2008. It was cool for a few days, but ultimately, I didn’t use it.


Yeah, there's not much point bothering if you're limited to a touchscreen

And if you're going to the effort of using a separate controller, you might as well use a separate gaming device.


There are controllers that integrate your phone and using your phone makes financial sense and reduces the hassle of having to carry a separate device.


Gamesir G8 Galileo is my winning option for USB-C (after trying Backbone One, Razer Kishi, and others.)

Makes for a pretty solid gaming* handheld, with a design that is similar to the Switch, Steam Deck, etc.

*(if you can find mobile games without awful monetization schemes)


> using your phone makes financial sense

We're talking about Apple devices here...


Anyone still making “Apple overpriced” comments hasn’t really looked at prices in a long time.

Starting prices of the normal phones:

iPhone 15 - $799

iPhone 15+ - $899

Samsung S24 - $859

Samsung S24+ - $999


Personally I'd rather be able to game on my beefy iPhone 15 with a clip-on gamepad than have to lug around a slow, loud, gigantic Steam Deck or a laughably primitive Switch


> Yeah, there's not much point bothering if you're limited to a touchscreen

Mmhm, I used to have a PDA [1] which had four hardware buttons below the screen and a D-pad, and that was rather nifty for that kind of games.

[1] Asus MyPal A620 – it came as part of a car navigation system which was gifted to us by some relatives. We never used the navigation part much, but because the whole thing was based on a regular Windows Mobile PDA which could run any software available, I appropriated it for myself :-)


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.


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?


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.


If Apple is compelled to allow users to run unsigned binaries (like Android) - would that allow for JIT emulators to run or is there something fundamentally blocking the execution of JIT code in iOS that prevents this?


There is no technical limitation, there is even an API for doing so.

It's just that apple block any submissions using that API from the app store.


iOS itself almost certainly also blocks usages of that API as well, unless the binary is signed with the correct entitlements.

But if Apple was forced to allow any binary to execute, and utilise any entitlement/API, then yeah there’s nothing stopping a JIT emulator running on iOS. But I think it’s very unlikely the EU would go that far, I don’t think such actions are needed for the EU to achieve their aims (liberalisation of app economy and markets).


IIRC Apple also doesn't allow apps to load binary code at runtime. Redistributing derivatives of ROMs also sounds like a copyright problem.


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 :/


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.


> Say, statically recompile the ROM on your PC

Basically impossible.

https://andrewkelley.me/post/jamulator.html


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.


That doesn't really help unless you bundle the game code inside the app executable. Otherwise you still need a JIT entitlement in order to map code as executable.


There is a lot of space between interpreters and a full JIT that is under-explored. Because developers typically skip straight to a JIT when they find a interpreter isn't fast enough.

Dolphin does have the cached interpreter, which eliminates some of the decoding overhead of a traditional interpreter, but I think you could go a lot further. Convert the PowerPC instructions to a optimal bytecode and apply various optimisations to that bytecode (function inlining, constant propagation). Common pairs and sequences of instructions can be replaced with a single bytecode implementation.

Given how fast Apple's cpu cores are, I suspect it might be possible to get a optimising bytecode interpreter fast enough so GameCube and other 6th gen console emulators can run at full speed.


I wonder how fast something like Forth-style direct threaded code could be on Apple silicon.


You could write a web browser that supports ROMs as script source.

   <script type="application/snes" src="…"/>
;)


Considering the number of ads I see for "gaming browsers" like Opera GX, I wouldn't be surprised if someone tries to sneak an emulator onto the store that way


Only if Apple approves it. They have time and money for lawyers.


Why would they need lawyers? They are writing and enforcing their own rules. I think enforcing compliance is more of an EU concern than yours.


Earlier than the GameCube even. The N64 audio was a programmable chipset (it’s late in my timezone so please forgive me for not including the full technical details here)


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


Connectix actually won a potentially important (though pyrrhic) victory against Sony:

"Video game emulation advocates have asserted that Sony vs. Connectix established the legality of emulators within the United States"

https://en.wikipedia.org/wiki/Sony_Computer_Entertainment,_I....


Connectix was the company (known previously for making the QuickCam, the first webcam for Mac), Virtual GameStation was their PSX emulator.


Also the company behind Virtual PC[0], which at the time was the most capable emulator for running DOS, Windows, and other x86 operating systems on PowerPC Macs. They sold Virtual PC to Microsoft and dissolved in 2003.

[0]: https://en.wikipedia.org/wiki/Virtual_PC


There are some great retrospectives on Connectix, I encourage you to find them on YouTube.


Thanks! I remembered the announcement but not the fine grained details. Mac was a very different world in the late 90s.


> in 1999 when Steve Jobs announced that Connectix [Virtual Game Station], a PSX emulator was coming to Macs

"Our goal is for the Mac to be the best game machine in the world."

And a great looking new game, "Halo" from long-time Mac developer Bungie.


Youtube "forgets" a lot. My history has more deleted videos than not.


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/


I’ve been emulating DS games on my iPhone for a while with a web app pinned to my home screen. It warns to backup saves (and I have) but I haven’t had any issues yet. It lags a bit if my phone is in battery saving mode, but otherwise works flawlessly. Crazy that “old” but also relatively recent systems can just run in a web browser now.

https://ds.44670.org/


Another very good web app emulator is https://afterplay.io. It also works very well within the browser or installed on the homescreen.


I’ve also enjoyed using desmume for DS emulation https://github.com/44670/desmume-wasm


What's a revoke? Why is it a problem?


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).


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.


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.


[flagged]


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.


Cool! I welcome the blue bubbles to my typical airplane ride for the last 12 years.

I remember having a work iphone and bringing an old motorola smartphone on the plane just so I could play Zelda OOT.


We need EU to force Apple to accept alternative browser engines on iOS. The iPad desperately needs desktop Chrome to become useful.


[flagged]


I will run Firefox with uBlock on mobile. I hope many others will as well.


Firefox has about 3% market share on desktop and declining each year.

And there are plenty of ad blockers on iOS.


Yes but almost all shackled by Apple. Orion Browser is probably the only one I've come across that lets me install uBlock and it actually seems to work. None of the other ad-blocking extensions for Safari have the same power as uBlock as per my understanding and usage.


I use AdGuard Pro on iOS Safari. I generally never see ads. The experience is pretty close to ublock origin on the desktop.


$10 closed source app that monitors everything in my browser. Hard pass.

Classic Apple swamp garden where users have to buy black box apps that are often free and open source in other platforms.


[flagged]


Still better than leaving people stuck on Safari. Now Apple will have to work to make Safari better.


The use of "retro" is interesting. Probably intended to exclude Switch emulators, but what will the cutoff be?


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.


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.


This is not really the case. The entire ROM catalogues of retro console systems are archived on sites for download.


The question isn't whether the ROMs are possible to obtain; it's whether there are sources of legitimate ROMs an app developer can direct users towards. The sites you're referring to are offering pirated ROMs.


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.


Insightful but disappointing.


There are Switch emulators for iOS [0]

[0] https://github.com/emuPlace/Sudachi



They may exist, but the implication is they won't be allowed on the App Store.


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.


Steve Jobs announcing PlayStation emulator at MacWorld

https://youtu.be/3OqMcqRI-xA?si=nUkGn6vLrLLMiGOP


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.


It’s trivially easy to take that same PSX disc, make an image of it, and load that into an emulator today.


The difference is that the PSX disc had some semblance of DRM or at least indicated ownership. Most ROMs are just copied.


That standard usage is part of what killed the Dreamcast. Just burn an iso of Sonic and throw it in.


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/


Wouldn't CAV decrease the amount of data that can be stored unless you're compensating for it elsewhere? I assume they used CAV so they wouldn't have to change the disc's speed when seeking to a different area of the disc.

The MIL-CD thing reminds me of the expansion port on very early playstations which was never used officially, but allowed exploiting the console by plugging a modchip into it.


I know the Dreamcast had piracy issues but I think the situation must have been more complicated. PS2 games can be read by standard DVD drives, and PS3 games can be read by standard BluRay drives.


Another use for emulators is accessibility. Using OCR, or iOS' image and screen recognition, I can more easily understand what's going on in a game. For example, since I am blind, I cannot see game menus, so in games which I can play, like Mortal Kombat, or the original Dissidia Final Fantasy. There are also games like Blazblue, which are mostly voiced visual novels, but with text describing what the characters do. So, OCR works great for that. I just hate the Blazblue character select screen, since it's a selection wheel you have to turn, and it doesn't just snap to a single character either, oh no. You have to turn it until you get to one, and then it has to be exactly on that one point. But that's okay.

My point is, if I didn't have emulation on a computer or device that has OCR and such, I wouldn't know much about the games I do play. Even tutorial messages are text, so in many cases I wouldn't even know how to play the game, especially in more complex fighting games like Dissidia Final Fantasy. So, running games on the one portable device I do have with accessibility, my iPhone, would honestly be great. And the DS has a few fighting games at least, so thanks to the person that shared that. Now we just need PSP! And PS1 does have MK, and Soul Blade, so that'll be really fun!


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.


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.


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.


IIRC you actually could copy from the phone or ipod back to the computer but you had to turn off automatic sync first.


Correct.


By not allowing me to run the full gamut of emulators - on the hardware I own - Apple is depriving me of my rights as an EU citizen.


You can run whatever you want if you sideload it, even apps with a JIT compiler. This is about offering apps in the app store.


> even apps with a JIT compiler

No you can't. Altstore does this with a hack, it enables remote debugging, which requires you to be on the same wifi network as the server.


This is a great change coming from Apple. I was initially surprised by this considering how Apple usually dislikes it when you want to find a way to run your own binaries on iOS devices.


Have any emulator apps been published and approved already?


App store review isn't that fast


We've been waiting since holidays last year for one of our updates to be reviewed.


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.


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/


2018? I missed that wave. I seem to remember they were cool in the late 2000s or so? Perhaps that was just me…


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.


i remember emulators really getting popular as a means to play the original pokemon games without owning a gameboy back in the late 90s...


Yeah, Bleem! was around since 1999.


When was UltraHLE? Like ‘98?


> 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.


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.


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.


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.


We have a direct comparison on the desktop be it Windows or macOS and it is definitely harder to sell software there.

The App Store and Play Store buying software a lot easier and increased the size of the market. Similar to Steam for PC games. But I also think that Apple should probably give developers better conditions.

As a customer of Apple I selfishly prefer Apple continuing to extract service revenue from developers. Because their shareholders expect growth and that has to come somewhere and I don’t want to pay for it.


> I don’t want to pay for it。

I don't get how you're not paying for it...assuming you're an iOS user, you bought apps and the devs passed on you the extra cost to pay Apple. Not counting for the ads you saw in the Store. You probably also bought extra space to backup your phone in iCloud, and as Apple is the only way for that.

Litteraly anything you paid on the platform went first to Apple.


> We have a direct comparison on the desktop be it Windows or macOS and it is definitely harder to sell software there.

How so?

On desktop, the race to the bottom hasn't hit as hard, and customers are more willing to pay sustainable prices for software.


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.


[flagged]


> 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.)


Nobody was begging for an app store lol


> 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.


  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.


> 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.


> 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?


Trust was also on that list, and that's absolutely a thing they can lose.

So far as I can tell, "trust" is the only reason Apple has for their rules about sexual content.


> So far as I can tell, "trust" is the only reason Apple has for their rules about sexual content.

Hey if Apple doesn't want sexual content on their app store, thats fine. But that isn't relevant to other app stores having that content.


They also don't want it in social apps. Telegram and Discord don't have access to the same content on iOS vs. Android.

I may be wrong (often am), but I can only model this as Apple thinking they have a reputation for being a "family friendly" platform and wishing to uphold that.

If so, I can see how they might consider being forced to allow a competitor that doesn't care, harmful to their reputation.

(Me? I think sex is fine and have a problem with realistic violence, and have been confused since I was 15 or so why films and TVs allow outright murder in kids' cartoons given how upset people get by even mere "wardrobe malfunctions").


> I can make money doing so.

Not everyone is interested in making money.


> 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.

Nah. It's because developers put a lot of effort in making Apple's platform great for many users.


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.


Further, they actively stifle competition on their app store. Want to launch an MVP? It's "too similar to other apps in this market."


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.


Everyone starts in the womb, but very few of us tread the same paths.


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.


Isn't this just picking winners with more steps?


Quite possibly, which is related to my doubt of their skill at judging similarity.


> If I wanna make an app for my mom's iPhone, I can't because Apple is preventing me

You can. You just add her to TestFlight and renew the app every 3 months.


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.


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.


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.


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.


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.


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.


> 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

I recently had a friend ask if I wanna join their YT Premium Family plan and they said it would be like 6 euro for me. Ended up asking how much they are paying as a whole and it was 32 per month and I immediatly knew that it was paid for on an iPad/iPhone, cuz even if you just go on the website on one of the devices it will show you the actual price of 24 euro.


Oh, no doubt this is ALL about money. I was just recalling the "official" reason.


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.


That rings a bell for me too, FWIW.


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: