Unless I'm forgetting something from the article, the author never said it was the LaTeX developer's fault -- he simply said Apple was right for not allowing it in its current state. Not all situations are someone's "fault", and thus just because Apple is not at fault doesn't mean the developers are. It's just as you declared it, an unfortunate result of many decisions which were right at the time.
That being said, I also think you have a low bar for definitions of "bugs". Terrible performance is very much a "bug" in my book. Even the things that aren't "bugs" in the strictest sense can still make for bad software. The executable described here is 4GB, that's 1/4 thte total space on a low end iPad! Also, if tomorrow someone does discover a bug, it sounds like this would be a mess to fix. The jumble of source simply won't be attracting many new developers (whether it be to fix existing bugs, add new features, or port to new platforms).
The LaTeX executable isn't 4GB, it's 3MB or so (pdflatex/pdftex) or 16MB in the case of XeLaTeX. The 4GB consists of billions of extension/modules/packages for typesetting documents.
Yes I noticed that in the comments before I posted which is why I was careful to specifically say "The executable described here is 4GB" so as to refer to whatever it is he was trying to work with. I suppose whether all of the 4GB is needed for what he wanted, whether it could easily be taken apart, or could now be remade in a much smaller package, are all valid questions.
4G is a bit over the top. My install (TeXLive 2010 on OpenBSD) is ~2G, and that includes gobs of rarely-used packages and documentation.
Really, borrowing MikTeX's install-on-first-use for packages and making documentation optional should result in a much more reasonable size. If you want to get fancy, teach LaTeX how to decompress packages on demand.
Here comes the problem: Apple requires it to be a single binary, distributed once. You can't install packages the LaTeX ways should you want to, so you have to bundle most (if not all) packages into the single binary.
You could use a virtual machine library (if anything suitable exists) and run everything inside one executable - it would probably have horrid performance but you get rid of the single binary restriction. You can put on a nice front-end and tell the user how much longer he has to wait until the operation is complete.
Virtual machines are generally prohibited by the guidelines as well. (Exceptions exist for things like script interpreters, which need to be present for some games to run, e.g. Lua.)
I think the difference here is between interpreting scripts that come with the binary, and downloading new scripts from the internet (or other untrusted locations). The latter is prohibited.
To get around it, you'd have to make it In App Purchases, because these also come from a the App Store.
Apple wants to restrict the platform options available to preserve their user lock-in. They were sort of forced to make an exception for games because they had no alternative to offer.
It seems the cult of Apple is touchy today and can't detect a joke. I'm sorry if I have inadvertently hurt your feelings - I will be sure to clearly state my humorous intentions next time. </humour>
For the record, I do not own devices based on iOS or Android and I don't care for your little Apple-Google feud with which you seem to be so concerned with. So please, carry on with those market statistics about Android, I am dying to know more.
Well you obviously weren't careful enough. Nowhere in the article does he talk about a 4 GB binary or binaries. To quote him:"A 4GB Tex distribution dependant on over a 100 binaries" He is talking about the _whole_ distribution not a single or several binaries. So even though you were careful, you still misquoted the article.
"The App Store guidelines insist that any iPad app be a single executable. Jailbreaking would ease this restriction, but in this case Apple’s gatekeepers are right. A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."
From that quote ("A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."), it is clear that he is musing about a scenario where he ships all 4GB. As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable. Thus, the theoretical distribution he is referring to would in fact be a single executable of about 4GB. In fact I think that's the whole point of those two sentences. So it appears that I was indeed quite careful.
> As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable.
On the other hand, yes the executable must be "one". On the other hand you can download stuff (either directly or via DLC). The issue is that while Apple has relaxed their restrictions on bundling interpreters in applications (you can do that), they have not relaxed their restrictions on downloading interpretable code: it's not allowed. So downloading even styles would be verboten, since styles are TeX, and TeX is executable code.
I think you are missing the point. The apple guidelines do not state that a program can only consist of an executable. That would not make any sense. Rather they state that any application can only consist of a single executable in addition to whatever resource files are included. In the case of the Latex distribution in question one would have to convert all 100 executables into one executable, my guess would be perhaps 100 megabytes. In addition one would have to include lots of resource files, mainly sty-files bringing the whole bundle of an executable + resource files up to 4GB.
AFAIK Apple doesn't restrict you from bundling files in your application. That simply wouldn't make any sense.
The point here is that he is talking about an application consisting of a single runnable binary of size X with tons of bundled .sty-files that brings the whole application up to 4GB.
Previously, this would not be allowed, since .sty-files are interpreted (which in turn would make it impossible to implement LaTeX on the iPhone), but that really wasn't the point here. The point is simply that this wouldn't be a single 4GB executable, but a an executable of perhaps 100MB bundled with a whole bunch of .sty (and other) files to a total size of 4 GB.
Edit: Fixed typos. Sorry. HN doesn't work very well on my phone.
That being said, I also think you have a low bar for definitions of "bugs". Terrible performance is very much a "bug" in my book. Even the things that aren't "bugs" in the strictest sense can still make for bad software. The executable described here is 4GB, that's 1/4 thte total space on a low end iPad! Also, if tomorrow someone does discover a bug, it sounds like this would be a mess to fix. The jumble of source simply won't be attracting many new developers (whether it be to fix existing bugs, add new features, or port to new platforms).