How exactly does runrev for ipad/iphone work?

[Richard Gaskin]

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