RunRev responds to Apple's new cross-compiler policy
Apple's new policy on cross-compilers has the development community in a frenzy, and for good reason. RunRev is reaching out to Apple and developers and voicing their opinion on the matter.
For those not familiar with RunRev, revMobile is a cross-platform solution that will allow developers to port their applications to several different mobile platforms with ease. Even though revMobile is still in its pre-alpha stages, it shows a lot of promise for developers who wish to develop for multiple platforms. It allows them to build their applications and not have to re-write code for each and every platform separately. This would provide an invaluable tool for devs. Now with Apple bringing the ban hammer down on cross-compilers, Adobe isn't the only one speaking up anymore.
RunRev has issued a statement with its thoughts on Apple's new policy on cross-compiler usage. Apple wants developers to create native applications originally written in Objective-C code. What this means is that developers will not have the ability to simply port over existing applications written in other languages. Apple voiced their concern over apps running natively and creating a more "seamless" user experience. RunRev isn't necessarily in agreement as to whether or not that's the best course of action. They've proposed a solution to this problem in an open letter to the community and Apple.
" ... In order to support our active and growing revMobile customer base, we submitted an in-depth proposal to Apple that we create an iPhone-only product that uses native Cocoa objects, supports 100% of their API, works perfectly with multitasking and battery life, but uses a variant of the revTalk language to use these objects and APIs, and then translates those into native code. While a significant engineering departure for us from the current revMobile path, this solution would have resulted in perfect-quality iPhone-only applications impossible to distinguish from native applications. It would have been impossible to tell these applications apart from native iPhone applications because they would be native applications. As native applications running directly without a compatibility layer, there would have been no battery life issues, multitasking and iAds would work perfectly, and new APIs would be supported as they came out. ... "
To me, this sounds like a reasonable solution. Apple has rejected this proposal and RunRev is uncertain what the future will hold for revMobile at this point in time.
" ... Some of our customers have suggested that we continue to develop the version of revMobile that outputs entirely native code (as detailed above). However such a solution--even though it would create perfect applications--would be in violation of Apple's agreement, which states that code must originally be developed in one of their approved languages. As such, we cannot risk hundreds of thousands of dollars of further engineering budget to create a solution that does not guarantee Apple acceptance to the app store. ... "
This is also understandable. The amount of development and time that would go into this solution is immense. As RunRev has stated, they're left at a stand-still as they aren't 100% certain that this solution would work or if apps created using revMobile would still face the App Store ban hammer. That's a lot of time and money to waste on an uncertainty.
This policy also will prevent the use of development tools such as HyperCard, which was one of the first successful rapid application development tools available. Not only do tools like this work, they provide an invaluable time management tool to developers. Not to mention HyperCard was written by Bill Atkinson, a co-founder of Apple. How's that for irony?
Perhaps Apple wasn't just after Adobe, as many originally thought. But where is Apple and why is it starting to feel like they're beginning to alienate more than just Adobe product users?
Thoughts?
[via RunRev]
Jailbreak, Mod, and DIY editor at iMore, Founder of PXLFIX, Potter pundit, the ninja in your iOS.
| Tweet |
|
|
← Previously
How to find and remove duplicate songs in iTunesLeave a Reply
Note: Comments must be civil, respectful, and on-topic. If a comment does not add to the conversation, if it contains spam advertising, or inappropriate language or content, it will be removed. Insulting the topic, author, staff, site, network, or other commenters will result in the comment being marked as spam and potential prevent future comments from appearing on the site. Do not post as a business or your comment will likely be confused with spam. Comments containing links may be held for moderation. Relax, enjoy, and share in the discussion.
Big surprise. Obviously they are not in agreement with it, it hurts their business model. Apple isn't the only company concerned about their bottom line!
Translations don't typically spit out applications as neat as one coded natively, so it's a bit misleading to suggest that they are identical in every way. You can build a solid translator that does, but risk having it all bunged up with a new update. And a perfect translator takes a lot of time and effort and money, so let's not act like one is likely to be produced.
That being said, while I do understand Apple's desire to avoid compatability layers (those run some more serious risks), I think it should be a developer's choice to use a translator. It's a stupid choice, but if you are too lazy or unable to code natively and want to make use of translated code, the market will decide if it's a good idea. If your code comes out too slow to use, then people won't buy it.
The problem is that Apple is dedicated to design and quality. They will happily rob you of free choice to make damn sure a program is as good as it can possibly be. That's a little strict, but that policy has brought them this far and has produced some amazing results. Ultimately, the public is an ass. They don't make elegant things, they spend money on fart apps.
I guess what I'm trying to say is, I see where RunRev is coming from but at the same time, they can go screw themselves.
Screw Apple!! Start developing for Android and Blackberry. When Apple starts to lose millions, they may have a change of heart. And lucky for us Android owners, they probably won't.
APPLE FAIL!
My thoughts on Apple...before i purchased my Iphone, Apple was just a Company, producing Macintosh's, a company appreciating design, expensive.... no real relation to them, after purchasing an Iphone, i started to get sympathies with Apple more and more, but now the last months.....damn, what a fu**ing company.
No Flash, No CrossCompiler-Apps, so many Restrictions for Users&Developers, questionable approval Process for the Appstore.
I still stand by the fact Apple has the right to make this decision but with great power comes great responsibility.
So many people are moving to Android because of the controversy but it isn't enough to hurt them. Where they are winning is apps. They lost Mac vs PC because of programs, in the early days, being written solely for PC. Now people are writing more iPhone apps than anything. If they keep stepping on developers and the apps become available more on Android than iPhone, Apple will become the loser in another battle.
Disclaimer: By "loser" I mean they will hit a niche (Mac users) vs mass penetration (PC).
And this is why I jail-broke my phone.
While I can kind of appreciate what Apple is trying to do in protecting the user experience, why doesn't Apple let me decide for myself what I want? If I want Flash running on my phone, I accept the fact the battery is going to die faster. If I want to install a non-Apple approved app, I accept the fact that it may not be a stable application. I'll deal with it.
Jobs is handing the market over to Android. The past is repeating itself again, ie. the Windows vs Mac.
-Android 2.2 is supporting Flash. -Android is on every wireless network or will be soon. -Android allows cross compilers. -Android leaves the ethical stuff out of the equation. -Android is being given away for free...that's for FREE! etc...
This so reminds me of the Mac vs Windows war...Back in the day we all wanted Macs but settled on Windows because back then Mac's were price restrictive. Today we all want iPhones but most will settle on Android because of the iPhone OS restrictions...
Lame.
@Cuthain - I would not at all say that the use of compilers brands a developer as "lazy". Yes there can be issues, but time is a huge resource and if you aren't getting a return on that investment, what's the point? Coding one app for multiple platforms takes a long time. Cross-compilers help in a huge way. Any good developer will cross-compile, test, tweak, test again, tweak again, etc.. but re-writing takes a long time when tweaking takes less time. As long as it runs native and there's no noticeable difference, I guess I don't see the problem
As far as things being slow or buggy, you really think Apple would allow them in the app store? There's already an approval process in place.
Yes, Apple has the right to allow or not allow development tools on their platform, but banning the use of cross-compilers altogether is a little on the extreme side. I'm very anti-Adobe for several reasons, but I think developers should be allowed the choice. Then evaluate apps on a per-app basis as far as approval goes. It's already done anyways.
A critical aspect of the article not summarized here is runRev's contention that EuroTalk intended to deploy thousands of iPads to schools in an educational pilot program for the Scottish government, and that Scotland may have to abandon iPads if they cannot use a RAD (rapid application development) tool like runRev. (xcode/interface builder is nice, but RAD it ain't.)
Yes, it is a veiled threat, but also a prediction with interesting implications. There is a large segment of the market out there for which RAD tools are a necessity, simply because getting a functional product out quickly is more important to the business needs than applying final polish. Internal corporate applications would be one, and education would be another. Should Apple service them, or ignore them for sake of App Store purity and risk them going to Android, WebOS, or whenever the Window tablet du jour gets released?
In theory, the self-distribution under an Enterprise License would work for these user/developers, but in practice it will fail, simply because no decent quality RAD toolkits will be made under current policies, and individual businesses and school districts have neither the time nor the expertise to create them on their own. With the door closed on the App Store, tool vendors (like runRev, or even gasp Adobe) will not invest the money to develop sufficiently high quality RAD tools for the iPhone.
The historical parallel is not to any tablet nor even to Hypercard, but to Visual Basic. Say what you like about VB's flaws (and they are legion), but VB contributed to the Windows hegemony as much as any other single factor, by giving businesses and small teams the power to craft or tailor custom applications internally without breaking the bank. Office itself may not have emerged as the 800lb gorilla without macro and VB tailoring. These VB apps ad Office mods, as crappy as most might have been had they been released as consumer products, powered untold numbers of businesses large and small, and still do. Most small businesses I know who might otherwise like to switch to Macs cannot simply because they depend on these single-purpose, focused apps.
The question for Apple is: do they see the iPhone/iPad as a tool for those types of businesses, schools, and teams, or not? If they do, they need either to repeal parts of 3.3.1/3.3.2 or supply, like MS did, a sufficiently powerful and flexible RAD environment, and figure some way for their Store to deal with a potential flow of lower-quality apps. If they do not, they will likely maintain a higher average app quality, but will shut themselves off from those other markets.
@(Copy of) Dev
that's why I linked the article
didn't want to make it ridiculously long but highlight the issue. but that's a good contention point too. several pilot programs and businesses depend on RAD.
Note to Steve Jobs:
"Those who cannot learn from history are doomed to repeat it." - George Santayana
Not surprising in the least.
"...and new APIs would be supported as they came out..."
This is exactly what Apple does not want - lag time or layers between new features vs. updates to frameworks and tools by 3rd parties to support said features.
What if Apple releases a feature that runRev decides not to implement due to technical incompatibility or difficulty? This is exactly what Steve himself is explaining as the rationale for this restriction.
Frankly, I'm stunned that they thought this proposal had a shot at all.
Also? I love all of the Android comments. Having recently used an Incredible that my mother ended up with, I wish them all luck.
I'm glad this is now finally being seen as something more than a simple attack on Adobe.
It is an attempt to leverage the 100 thousand app store apps to starve Android of developers. To make it too expensive to develop for more than one platform, in the hopes all developers will remain only with Apple, or will develop FIRST for Apple, and then port from Apple to something else.
This will probably fail, because they waited too long. Android sales and android app store has reached critical mass. The horse is out of the barn.
However it does raise yet again specter of illegal restraint of trade. You cannot tell a carpenter which brand of hammer they must use. Not in the US. Not in Canada. Not in Europe.
(And if anybody raised the "M" word here I will grab them by the wattles and slap them till they spit. Don't even go there. If that's the extent of your business law knowledge, just don't post at all.)
@Kilsay:
So what if they do?
They lose their market to those more willing. Non of the existing apps developed with these tools would require this new feature to continue to run.
But if it was a desirable enhancement, the probability of it appearing rapidly in hundreds of apps is ENHANCED by its inclusion in the dev tools, not hindered. Which is harder: trying to jack up 3000 independent developers to study up the feature, add the feature to each of their apps, or add it once to the RAD tool, and get 3000 users to do a simple re-compile?
This is a bogus argument.
@icebike
I agree with you, the Android horse is out of the barn. Apple would be smart to repeal parts of 3.3.1 and 3.3.2 and get some of that developer love back. They are losing it all so quickly!
My iPhone contract is up this month. I am giving Apple until WWDC. If Android runs Flash well enough, I have to move over to Android Central. Sorry Rene.
@icebike, who can't read my name, apparently
Who do you think that users will complain to if their apps aren't updated to take advantage of the latest features?
runRev? Clearly not. Who the hell are they to the user?
No, they'll go to the Genius bar.
Is there an element of wanting to have developers use XCode and be well-trained on coding iPhone OS apps? Of course. They'd be silly to be encouraging developers to code in something other than what they believe provides the best possible user experience. In this case, that's Objective-C using the iPhone SDK.
Apple is not in the smartphone business, MP3 player business or the computer business - they are always, first and foremost, in the user experience business. They don't give you just a phone, they give you a miniature computer that can become a million other devices. It's not a computer that you have to maintain, but a tool to get things done that simply works. 9 times out of 10, that experience is pretty positive, as evidenced by rising market share in different device categories (for the most part).
And while sure, existing apps would continue to run, the fact they they were not updated would likely result in a negative user experience. That you list this as a benefit baffles me. My cassette player still runs, but that's not nearly as useful to me as more current, desirable technology that is smaller in size and larger in capacity. If Pandora was written using a 3rd party framework and that framework could not properly implement the new "multi-tasking" features that have been previewed for iPhone OS 4.0, would that be a positive experience for users?
Whether a new feature was desirable or not does not change the feasibility of its technical reproduction in a 3rd party compiler/dev tool. Sure they might be more likely to try to duplicate or implement the functionality, but that does not mean that they can or will. And that's where lag or differing feature support levels come in, and customer support and marketing headaches begin. It is an iPhone OS App Store. Not a Flash App Store or a runRev App Store. It's associated with the Apple brand and user experience, and it's only logical that Apple want to protect both of those assets.
And ultimately, if they're wrong, then Android will thrive and Apple's market share will shrink. That's their horse in the race, and they could lose.
I just don't agree that it's a restraint of trade issue.
@Kilsey
I must have missed the massive flood of people to the Genius Bars to complain directly to Apple when their Twitter clients did not have Push Notifications when 3.0 was released.
Then again, for 6 months after OS3's release, I almost could not walk into an Apple Store, because of the sheer mass of humanity teeming around the Genius Bar to blame Apple for ESPN Scorecenter's lack of Push.
Entities that require Rapid Application Development platforms are the perfect opportunity for HTML5 apps. Need access to the phone's camera, contact data, microphone? Doesn't sound like an app that should be rapidly developed to me, but then I actually appreciate the curated user experience of my iPhone just as much as I appreciate it on my Xbox and my Wii.
@(Copy of) Dev
I misspoke. They'd whine here and on other message boards.
Oh boy. I agree with (Copy of) Dev's bottom line: Apple's next move should be to release their own RAD application, and make it cheap and easy. The intention of some, above, to switch to Android because it supports Flash, is probably false or, if not, silly. The iPhone OS maybe just isn't for geeks, and they can fiddle with Android instead all they want. The iPhone OS devices are consumer electronic devices like Somy's Walkman or microwave ovens, not 'computers' we can all tinker with to our heart's content (or if you sply must, jailbreak) -- in any case Apple can, will, and must control the software that (legally) goes on them, or granny and I are going to be at the mercy of everybody who thinks our iPhone OS ecosystem is their own private playground.
@Lady Kaede - agreed - that's exactly what I was talking about with user experience
I've tried Android and found it similar to my Treo days - lots of fiddling, things worked some of the time, but I wasn't enjoying the experience.
"Children And Infants Require More Proof" Parents traveling with children under age 16 and infants are required to provide proof of citizenship for each child. That may include original or copy of Birth Certificate, Consular Report of Birth Abroad, Naturalization Certificate or Citizenship Card. If both birth parents are not traveling you must have written authorization from the parent(s) or proof of custody. Failure to provide such evidence may make you inadmissable to Canada.
Apple's "user-experience-business" is near to end or better said not that competetive like years ago. It's still amazing, no question, but the Big Lead is over. It's amazing how far Android allready has came if you imagine, how long android exists and that google never had any experiences in "mobile-plattforming".
Google's mantra is "Don't be Evil", now they added "mobile first" as mantra. That say's everything. They even put their best programmers to "mobile".
What's Apple's mantra..."Be Evil"?
@lady kaede...yeah, it's false and silly to buy an android just for flash, i mean what do i get? I will have the full webexperience, can watch all the movies, streams, games, any flash website, fun stuff, anything, to 95% just like desktop. No fu**ing blue building-set. What a silly reason ^^
And where is the news about HULU NOT SWITCHING TO HTML5, they keep Flash as Videoplayer. Strange, these news didn't arrive TIPB ^^
@El Pedro:
Well said. You don't need a full blown native app for everything. For most projects in need of RAD-tools HTML5 should do just well. And it is fully cross-platform without any need for cross compiling or run-time environment.
But what if you enjoy the fiddling? What if you don't like the fact that there are features that the phone has available, but Apple has chosen to lock out from you? MMS was available to jailbreakers a year before Apple let it out. Multi-Tasking was enabled by jailbreakers, but Apple took forever to allow it. WiFi synching is available to jailbreakers, but Apple has denied it.
So tell me why Apple sits on functionality that their hardware and software are capable of doing now? So that they can slowly parse it up in updates and say "look at all this stuff we're developing for your benefit!" They say they want to make sure developers take advantage of all the functionality the phone has available now, but then they block developers from implementing functions until Apple is ready to allow it. Why? I realize some stuff may not be ready for primetime, but Apple doesn't like people being more innovative with their product then them. They want that control, regardless of how it may benefit the consumer.
Apple will probably win this just because the majority of consumers don't know nor care about any of this. And that's fine. But I don't need Apple preaching to me what's in my best interest. At least provide some options if some of us want out from Apple's software jail. I'll gladly opt out of warranties for that freedom.
Why on earth is this company blaming Apple? RunRev created their own issue by starting a business that relies solely upon what the large electronics companies produce. Without iPhone OS, Android OS, or Web OS, RunRev wouldn't even be in existence and this cross-complier story would not even be an issue worth discussing. Now they are upset that Apple is cutting them off, when it is Apple that began feeding them in the first place. I'm sorry, but that is just a poor excuse for a failing business model. They do not address how new API's will be supported when they come out, particularly how QUICKLY they will be supported. This is one of Apple's major concerns. They don't want to wait around for RunRev to update their cross-complier software for developers to be able to utilize the new API's and update their apps for new functionality. As an iPhone OS user, I don't want that either.
I'm sorry RunRev, Adobe, and anyone else who sells cross-compiling software, but don't blame Apple for your poor business planning.
It's not a win if what you do results in someone not you winning. Cross platform development marginalizes hardware and OS vendors and potentially hands over control of the platform to the cross platform vendor, be it Adobe Flash, MS .net, or this runRev company. So all you Apple fans are arguing for Apple to promote a situation where they lose and some other company wins. The customer wins definitely, but it's not a victory for Apple. If Apple doesn't win, users really don't win from my POV.
Cross-platform development will result it being easier for customers to move to different systems and to create a situation where hardware vendors have to race to the bottom. Low margin hardware with non-unique software is the antithesis of what Apple is.
It's simple, use the native tools if you want to be in the Apple app store. There isn't much merit to arguments about needing cross-platform tools or RAD tools or whatnot being better or whatever.
But....why not to develop an application in native Cocoa and THEN translate it to other platforms. That's a win-win situation.
@Johnsen - I'm not sure I understand your meaning. In my opinion, Apple pays a heck of a lot more attention to user experience than Android does, and my personal experience bears that out. Sure, Android is a credible competitor, but given the choice I'd go with the iPhone 11 times out of 10
Also, if you're deciding on Android based on the POSSIBILITY of a workable Flash solution, I'd say that's a silly reason. Also, re: Hulu, they're sticking with Flash for DRM reasons for now. I'd expect a native iPhone OS app soon.
@DT - if you enjoy fiddling, more power to you. To some degree, I'd bet that Apple could stamp out jailbreaking if they really put their mind to it (for instance, Skype can seemingly detect a JB phone), so by not truly going after JBs perhaps that's their way of saying, "Go ahead and fiddle, but we're not fixing it if you break it."
@matt & @shrike - agreed 100%.
@kilsey
Well of course they will be -- message boards are for whining
But they won't be whining about or to Apple -- they'll be whining about Program X to Program X's maker, which makes the point about a drain on Apple moot.
I do not understand why Apple is doing this. In the gaming industry, console giants like Sony and Microsoft develop tools for developers to make a game for one system and port it easily over to another. This seems to work out in favor for the console, the developer and the consumer. But what Apple is doing is making it harder for developers to write apps. What this can cause is developers who are not big enough to pick sides. With the Android OS growing rapidly and hardware coming out with new features for developers to play with and make apps for, it might cause developers to lean more on the Android side rather than Apple. Just my opinion...
@Shrike/@kilsey
You are missing the point. Unlike Flash, runRev and tools of its ilk are not primarily about cross platform development; they are about rapid development -- an order of magnitude or more faster than what you would get in xcode, or eclipse, or visual studio, for that matter.
If it helps, think of RAD tools like kilsey thinks of the iPhone compared to Android. As he says, he does not like to fiddle. In customer speak, with the iPhone you do not have to fiddle, you just go about your business, and "it just works."
RAD tools are the same way, for developers. In Obj C, you have to worry about object ownership, retaining and releasing, and all sorts of little things. In C/Obj C, you have to fiddle; failing to address these issues can yield slowdowns or nasty bugs, but these concerns really have nothing to do with the content of your application. A well-designed RAD tool frees a developer from having to worry about these things, so they can focus on the business/creative side of the application, while the rest "just works."
While such a toolkit definitely puts an upper bound on the type of applications you can create -- nobody is going to write Mobile Quake with runRev -- for the level of app in its sweet spot, good RAD tools offer an unparalleled level of productivity. Your dentist's office or your insurer is the same way -- they do not have the time or money to hire "real" developers, and they don't want to fiddle; they just want to adjust their billing and appointment books, so they can get back to their real work. For the business or school that needs a quick custom app that just works, the availability of RAD languages and tools can be the difference between success and failure. Would the general consumer buy RAD-developed apps? In most cases, no, but there are exceptions. Even so, BILLIONS of dollars go towards them annually, and they can tip a market.
Jobs recognizes this; he specifically said at the last shareholder meeting that a Hypercard-type product for iPhoneOS would be a good idea, but that "somebody would have to build it." runRev apparently attempted to do just that, but was shot down. If Apple is not going to let somebody else fill that niche, they had better do it themselves, or some other platform will have a big, BIG opportunity.
It's not a win if what you do results in someone not you winning. Cross platform development marginalizes hardware and OS vendors and potentially hands over control of the platform to the cross platform vendor, be it Adobe Flash, MS .net, or this runRev company. So all you Apple fans are arguing for Apple to promote a situation where they lose and some other company wins. The customer wins definitely, but it's not a victory for Apple. If Apple doesn't win, users really don't win from my POV.
Cross-platform development will result it being easier for customers to move to different systems and to create a situation where hardware vendors have to race to the bottom. Low margin hardware with non-unique software is the antithesis of what Apple is.
It's simple, use the native tools if you want to be in the Apple app store. There isn't much merit to arguments about needing cross-platform tools or RAD tools or whatnot being better or whatever.
@Bruce
I guess it is true; repeat something often enough and you start to believe it.
@(Copy of) Dev
It's simple, if runRev wanted to do a RAD tool for iPhone OS, they should use Apple's native tools instead of cross compiling. If it spits out C-based code that runs through Xcode-based LLVM/CLANG or Webkit/Javascript, I don't think it'll matter to Apple. Whether one will come into existence be it from Apple or a 3rd party, who knows.
Look, people keep saying "this is Apples right and of course Apple is going to do what's best for Apple" - No one is contesting the LEGALITY of this action. Of course Apple is free to do this.
The point is that it's worse for iPhone users (less Apps available in the future) and the general smartphone ecosystem. Allowing cross compiling - when has it backfired? Never. It simply makes more applications available on more platforms. If the quality vs. time tradeoff is enough, then people will develop native versions. If the cross compiled version is indistiungishable, then they will not. Yes, sometimes cross compiled things suck, Windows applications often don't work in Wine on Linux. But having Wine available allows you to run windows applicaitons you wouldn't otherwise be able to run - it's only a positive.
And if Apple really is concerned about the average user, just make a setting deep in the bowels of the iPhone that would allow a person to use third party applications or cross compiled applications. If it's hard to access, the newbie users will be protected, but people who want it would have the option. Of course Apple is not going to do that, because their concern is NOT protecting the user, it's locking down developers to the iPhone.
A seemingly pervasive notion that I glean from many of the comments above is that of a superiority in Apple products and that because of that perception, whether or to what extent that it may or may not be valid, Apple ought to remain distinct or “superior” in that regard. I submit that it is, as always has been and will continue to be, a consumer-centric and consumer driven marketplace – not one of Apple or any such oligarchical company. Any attempts by Apple or its loyalists to stifle, restrict or essentially even guide the progression of technological development or consumer response based on any such notions is ultimately destined to fail. Apple tried that in the 80’s and sustained itself in that folly while it lasted (while it arguably had certain technological and experiential advantages), however; in distinction to the relatively narrow and restrictive Apple model, the synergy of diverse technological progression that freely flourished and developed concurrently within the diverse and open development arena and market, that cycle of Apple has come to an end. Also to be noted, in the 80’s, personal use of technology was in it’s infancy and Apple’s simplicity enjoyed a certain lowest common denominator appeal. Sine then, there has been and will continue to be the emergence of new pre-wired generations and a more and a more technologically adept market. Apple (like Adobe) may be considered now, or will be very soon, just another player. It will have to play by objective market competitive standards rather than any no longer substantive claims to any superiority – technological or experiential – either from itself or its enthusiasts.
@Matt: Then Apple is stupid for depending on Intel, Foxconn, ARM, PowerVR, Cirrus Logic, Samsung, etc... Without these companies, Apple wouldn't exist. And guess what, without a bunch of other companies with relationships that we don't even fully understand, the companies that Apple depends on wouldn't even exist. There's even an entire field of study dedicated to figuring this out. It's called Economics.
Any of these companies could put out some arbitrary restriction on what can or cannot be done with their chips. The only difference between RunRev's business plan and Apple's is that Apple has a larger set of companies to choose from, and buys enough from many of them that it would be a bad idea to prevent that.