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
