If apple is apples policy is contingent upon the purchase of the blessed IDE than a court will shortly slap it down. Count on it. But the battle could rage on a bit if apple is giving the blessed IDE away.
Randall On May 6, 2010, at 11:19 AM, Richard Gaskin wrote: > Randall Reetz wrote: > > > Is there a resource online or a white paper that describes in basic > > language how runrev for mobile (specifically for apple products) > > works? Does it use apple's blessed dev environment at any step in > > the process? In what form are the final builds? Does it require a > > player app to be installed on each devise? In short, how does runrev > > for mobile differ architecturally from the fully blessed apple > > environment and app format? > > The last build RunRev shared with its early adopters worked in a way that was > compliant with the license terms in force at the time they started that > investment, but which has since become redefined by Apple as verboten: > > You wrote in RevTalk, which the engine then compiled down to a form of object > code that would run well on the iPhone with no player and no interpreted code. > > But under the rules in effect as of 11:19AM this morning (which may change > again by this afternoon), one of the unprecedented elements of the license is > that Apple limits not only the state of the deliverable object code, but also > the provenance of the source code: > > 3.3.1 — Applications may only use Documented APIs in the manner > prescribed by Apple and must not use or call any private APIs. > Applications must be originally written in Objective-C, C, C++, > or JavaScript as executed by the iPhone OS WebKit engine, and > only code written in C, C++, and Objective-C may compile and > directly link against the Documented APIs (e.g., Applications > that link to Documented APIs through an intermediary translation > or compatibility layer or tool are prohibited). > > For more on this provenance aspect see Hank Williams' post: > <http://whydoeseverythingsuck.com/2010/04/jobs-bans-non-c-libraries-insane.html> > > The "must be originally written in" clause is the killer here. Even > translating RevTalk to generate C/C++/Objective-C code which was fully > compliant with all technical aspects and in all ways indistinguishable from > human-written code would be punishable under criminal law. > > Whether using psuedocode during design, as is a common practice, also > violates this clause has yet to be tested. > > > > What are the current plans and how have they changed runrev's > > previous plans for the revmobile product's base architecture > > and release protocols? > > Currently unknown. > > Kevin has noted here that he is in negotiations with Apple to determine the > best course of action in light of their sweeping and unexpected change, and > will report back here as soon as the outcome is known. > > As currently written, Apple's current iPhone license agreement seems to leave > only four options available to developers: > > 1. Developing using Apple APIs in only C/C++/Objective-C; because > of the unusual provenance clause this option does not appear > to be available to RunRev at this time. > > 2. Develop using JavaScript and WebKit; possible for RunRev, but > while some of us do a bit of that in very limited ways it would > no doubt be very costly to generate JS from the whole of RevTalk > (though Toolbook kinda did that in a useful way). > > 3. Develop for the rest of the world and wait for Apple to change. > > 4. Develop for the rest of the world, and for iPhone OS deploy only > for "in-house" use under the special provisioning rules that > allow it, bypassing the AppStore. > > I've seen nothing in the license or discussion of it which suggest there is a > fifth option; at least any fifth option that doesn't leave developers even > more exposed to risk than they already are. > > I'm confident Kevin will choose from the limited options Apple has provided > its developers the one that's in the best interest of this customers. > > -- > Richard Gaskin > Fourth World > Rev training and consulting: http://www.fourthworld.com > Webzine for Rev developers: http://www.revjournal.com > revJournal blog: http://revjournal.com/blog.irv > > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
