Earlier quoted context omitted.
OS X isn't.
Neither is Windows.
Couldn't you concievably develop with Mono, though?
Antitrust inquiry into Apple over Section 3.3.1
91–100 of 130 posts
Re: Antitrust inquiry into Apple over Section 3.3.1
#92Earlier quoted context omitted.
>How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3? >For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code) XNA requires you to target the .NET runtime. It does not dictate what t…
The specifics are different, no doubt - but the ethos is the same. Microsoft force you to use .Net (of some form) and their APIs because that fits their business model (i.e. ties you to the XBox). They're restricting me from using my platform portable pure C code, which is their choice. I obviously don't know, but suspect if large amounts of code started targeting XNA in a cross platform way, they'd come down on that…
> Microsoft force you to use .Net (of some form) and their APIs because that fits their business model
You can always develop in Java with your favorite tools and transform the generated bytecode to .NET using IKVM. You can have your own abstraction on top of XNA and SDL, so you don't have to change anything when porting a game from the JVM to the XBox.
Nothing stops you from developing cross-platform apps, and in fact major games publishers are doing just that ... any game that's running on both the XBox and on Playstation 3 is using a intermediate layer.
Yeah, it's costly to distribute object code compiled from C/C++ or your tools of choice, but you have that option.
So wtf specifics are you talking about?
Re: Antitrust inquiry into Apple over Section 3.3.1
#93Earlier quoted context omitted.
>> Prior to the iPhone, there was virtually no real development allowed on phones that achieved any levels of success (carriers had the platform locked down hard). cough The development for mobile phones partially sucked (and still does, partially; it's in the nature of the beast I suppose, for now) before the iPhone, but I don't know about it being not allowed. You have to draw a distinction between so called featur…
Your entire response seems to have missed my "allowed on phones that achieved any levels of success" qualifier. Name me any pre-iPhone development platform allowing development that had ever created a truly viable marketplace. There were a few faltering attempts with Windows Mobile and Symbian, but frankly, they were terrible. And yes, I am conflating development and the distribution channel, but this seems fine to m…
> There were a few faltering attempts with Windows Mobile
In 2003 I had a iPaq PDA with Pocket PC 2002. It had a marketplace ... some of my apps where sold by the local HP distributer and I was quite happy ;)
These devices where not mainstream because of poor hardware capabilities, and because of the lack of public Wifi / 3G networks, but still I was amazed by how much it can help me organize.
Apple makes cool products and its timing was perfect. That's about it.
Re: Antitrust inquiry into Apple over Section 3.3.1
#94Earlier quoted context omitted.
> I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on. So you've never encountered a standard/API/platform that perpetuates bugs, support for bad practices or misuse of old interfaces to avoid breaking legacy apps?
Good platforms get updated instantly and aren't using too many unofficial APIs. If something so awful happens on an upgrade that it breaks such a middle layer, it will also break many native apps which will also need upgrades. Also, applications written for cross-platform development tools are higher-level and for complying with any new interfaces you may have it's just a matter of rewriting some bindings. In case th…
It's hardly a strawman. The history of personal computing is littered with examples of this, many of which have been covered ad nauseum during this 3.3.1 debate.
Your argument, in contrast, is alternately "that doesn't/won't happen" or "that's no big deal". Which is an assertion that stands against the piles of evidence that it does and is, and an assertion you don't back up at all. Why should middle-ware be different this time?
For the record, I don't think middle-ware decay is a reasonable argument for Apple disallowing it. (I do think it's the argument against developers relying on it.)
I'm just getting rather tired of people either misrepresenting or ignoring the other side of an argument. There's plenty there to disagree with. It makes no sense to pretend that middle-ware decay doesn't or --for unspecified reasons-- simply won't happen this time.
Re: Antitrust inquiry into Apple over Section 3.3.1
#95Genuine question: How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3? For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code). However, Microsoft/Sony/Nintendo still seem to be allo…
>How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3? >For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code) XNA requires you to target the .NET runtime. It does not dictate what t…
As far as I can tell, there's no way to deploy an XNA game to the 360 that hasn't been built with Microsoft's toolchain. I think it's a bit early to speculate about the differences between the two platforms (iPhone OS and X360).
Re: Antitrust inquiry into Apple over Section 3.3.1
#96Earlier quoted context omitted.
>> Prior to the iPhone, there was virtually no real development allowed on phones that achieved any levels of success (carriers had the platform locked down hard). cough The development for mobile phones partially sucked (and still does, partially; it's in the nature of the beast I suppose, for now) before the iPhone, but I don't know about it being not allowed. You have to draw a distinction between so called featur…
Your entire response seems to have missed my "allowed on phones that achieved any levels of success" qualifier. Name me any pre-iPhone development platform allowing development that had ever created a truly viable marketplace. There were a few faltering attempts with Windows Mobile and Symbian, but frankly, they were terrible. And yes, I am conflating development and the distribution channel, but this seems fine to m…
Since in your eyes the iPhone is the _first_ smart phone that qualifies for "any levels of success" it is of course the most open.
I think several smart phones were successful (at least in europe) and had a more open development environment. You could install unapproved apps (up to S60 2nd ed. After that some APIs were restricted for unsigned apps. But even then you could buy those certificates). There was no company I know of that disallowed satire or certain programming languages or interpreters on their phones.
Those phones were:
Sony Ericsson P800 (you could even run javac on it in) and its successors P900/P910
Several Nokia S60 phones before 3rd ed.
With limited APIs S60 3rd ed. like the Nokia E90 (my last phone before the arrival of Android phones)
Re: Antitrust inquiry into Apple over Section 3.3.1
#97This is absolutely retarded. a) The market will figure this out. If developers don't want to code in just Cocoa touch or make apps for other platforms a priority because the language is easier, they will. b) Things are in such a nascent stage. Android is growing like a weed. A suit like this might make some partial sense a few years down the road if there was enough data there. c) The department of justice will proba…
Regarding d, you CAN (theorically) build an XNA game with any tools you want. It just has to be compiled to .NET bytecode and use the microsoft APIs for accessing system resources.
Nobody is saying that apple has to give developers the ability to run native code, or to use private iPhone APIs. What they are saying is that Apple shouldn't be able to require us to use C/C++/Objective C to create the executable. That would be like Microsoft requiring XNA to be build with C#.
Re: Antitrust inquiry into Apple over Section 3.3.1
#98Genuine question: How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3? For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code). However, Microsoft/Sony/Nintendo still seem to be allo…
There are in fact technical reasons why XNA games need to run on the CLR. The XNA CLR stack implements aspects of the security model.
The fact that the 360 itself can run "native" code (in fact: hardware-managed code running in a VM) is irrelevant; Microsoft has onerous licensing and contractual agreements with the people they allow to write native games. On the other hand, anyone can write an XNA game.
In point of fact, XNA is more burdensome on X360 developers than "3.3.1" is on iPhone developers. For the most part, iPhone devs are on a somewhat level playing field with Apple (there are clearly exceptions, but the showcase apps on the iPhone tend to come from third parties). Apple's restrictions lock developers into 95% of the same platform as Apple itself uses. XNA is a second-class citizen on the XBox 360. Microsoft does not allow random people to write full native Xbox titles.
Re: Antitrust inquiry into Apple over Section 3.3.1
#99Earlier quoted context omitted.
All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Adobe's delay in switching to the more modern APIs is the reason why they couldn't ship a 64-bit Photoshop for Mac until now. As Jobs has explained, they've been burned before.
>All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Humorous given that Apple has several very prominent apps (iTunes, Final Cut Pro) that still have made the migration. And they control both sides! However that is irrelevant. Tell me again how, if Apple revises the API, that suddenly every…
Could you stop using words like "vapid", "ridiculous", and "asinine"?
Developers who build on Flash can't multitask until the iPhone Flash runtime exposes the multitasking API. The developers of those applications are beholden to Adobe to get access to a core iPhone OS feature. This is not a complicated argument.
Reasonable people can disagree about whether this is a valid reason to lock down the compiler toolchain for the OS. But I don't think a reasonable person can pretend that there's no opposing argument, no matter where they start from.
Re: Antitrust inquiry into Apple over Section 3.3.1
#100Earlier quoted context omitted.
>> It just doesn't want them on the app store. Where else exactly could they go? >> Forcing Apple to repeal 3.3.1 doesn't allow offending software to be built and sold (as it already can be), it forces Apple to stock its shelves with it Those two things are the same, by Apple's design.
Cydia or the other jailbreak market (can't recall the name). Those certainly aren't remotely equivalent options, but my point was just that 3.3.1 is about Terms of Use for the App Store, not an attempt to legally stifle an existing secondary market as with car parts and ink cartridges. It's thus a qualitatively different situation. More relevant precedent might be found by looking at other situations where service pr…
[deleted]