Exactly, which is why if this gets any traction I believe it'll be removed. Apple does not allow you to consume your own content on their platforms without a tax or at least a little roughing up.
VLC’s doing fine. It’s how our kids watch movies on road trips (download to iPad from Jellyfin’s web interface, play in VLC).
Almost every book I’ve read in Books is from libgen. Download, open-in, and it’s on all my devices. Reading progress syncs and everything.
The best electronic comic book experience I’ve seen is from a free app (optional one-off IAP that does nothing—I wish it had higher tiers, the author is doing god’s work and I’d have given them $50 or something, no question). I put related cbr and cbz files in a directory in icloud, they show up seconds later in this app, it quickly figures out what they are (no clue how it’s as accurate as it is) and organizes them, and I get to reading two pages at a time in landscape on a 12.9” iPad.
The only Apple content I pay for is Apple Music, because it’s so damn convenient and I listen to way more music when I have it. I used to put my own music files in the exact same app, though, and that worked fine.
> The only Apple content I pay for is Apple Music, because it’s so damn convenient and I listen to way more music when I have it. I used to put my own music files in the exact same app, though, and that worked fine.
You can still do this, but you have to use a Mac or Windows PC to do so. It’ll sync your music up as part of a cloud library that exists alongside Apple’s licensed music. It’s the reason I go for their service vs. Spotify (which will let you sync music locally to their app, but doesn’t have a cloud library).
Does VLC have any extra codec support (read: software decoding) compared to what Apple makes available via APIs? I think the only thing I've noticed is webm files being playable in VLC and not when opening via the `files` app, but the vp9 codec is hardware accelerated and has been available for playback in apps for years (the YouTube app shows it in use a lot).
Can’t speak for VLC because I don’t use it that often, but other apps like Infuse support extra codecs (including vp9) beyond Apple’s offering, so AFAIK there’s no limitation on this from Apple’s side.
iSH has compiled the binaries for arm64 so they actually run natively. When they do a syscall to malloc they are actually doing a syscall to malloc.
iDOS is interpreting the bytecode and wrapping the unavailable things with its own implementation. When a DOS application runs malloc, the memory is assigned by iDOS instead.
I’m not saying Apple is consistent, but your example doesn’t show that well.
"Possibly the most interesting thing I wrote as part of iSH is the JIT. It's not actually a JIT since it doesn't target machine code. Instead it generates an array of pointers to functions called gadgets, and each gadget ends with a tailcall to the next function; like the threaded code technique used by some Forth interpreters."
You're thinking of a-Shell, which does offer compiled & locked binaries in a command line environment on iOS (via "ios_system"). Even then, they also support running WASM/WASI modules in a-Shell's command line environment.
Though it doesn't invalidate the gist of your saying, malloc is a user-space function not a syscall. (Its implementation will occasionally do a syscall, such as to sbrk or vmmap.)
> 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 apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
This is not as cut and dry as you might think it is.
> Apps should be self-contained in their bundles, and may not read or write data outside the designated container area
This refers to the storage container each app gets, once a user loads up a script into the app, it’ll be stored within its container. So there’s no reading or writing outside its container area.
One could argue that the app itself isn’t self-contained in its bundle, but that depends on how you draw the lines. If your definition is that the app is an emulator then it’s self-contained within its bundle, if however you contend that the games you load in are to be considered part of the app and that those games are to be deemed apps then it’s not self-contained.
> nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps
There is no downloading or installing code, but there is executing code. Again, does executing this code change the features or functionality of the app? If your definition is that the app is an emulator, then no, if your definition is that when it runs these games it changes the app then yes the execution clause applies.
At face value the app, the emulator, is not changed and is self-contained, but reasonable minds can differ.
Nevertheless I don’t think the app it at risk for its functionality, rather it’s at risk for being under GPL license as per the App Store listing.
This is because Apple doesn’t allow GPL licensed apps on their App Store courtesy of the FSF[0] who tried to force Apple to change their App Store terms with a gambit by submitting an app licensed under GPL, to then turn around and complain that Apple’s App Store doesn’t comply with the GPL license by virtue of not distributing the app without DRM and other restrictions.
Apple’s response of course was to simply remove the app in question and adopt a silent policy of not allowing GPL apps (and other apps with a license that collides with the App Store ToS and license).
Yeah, ScummVM runs the original game scripts, doesn't it? And the original games aren't bundled with it (they can't be). Kind of surprising they got away with violating that rule.
ScummVM explicitly denies being any kind of emulator.
It doesn't run the original source code of the games. Rather, it's a complete rewrite of the game that uses the original assets (images, sounds, internal scripts, etc.)
Yes, but those games contain scripting languages, like Lua for Grim/Escape from Monkey Island. That isn't shipped with the app, so it technically violates the rule. Hope they keep it up though, or if not, hope they get their ass kicked into allowing third-party app stores soon so that you don't need to jump through massive hoops to use anything like this.