Quoting that post:
> <...>Apple proposed updating its Terms of Service for iPhone OS 4.0
The § 3.1.1 in question is in the new "iPhone Developer Program
License Agreement" which replaced the old version in "Legal
Agreements" section in my "Member Center" as soon as I agreed to it.
And there was a warning that if I would not accept to the agreement by
April 22th, I'll loose access to the provisioning portal.
I think this agreement change is not related to the 4.0 release which
would be released in summer and which I would not be forced to use
until all previous versions of iPhone OS would no longer be supported.
Do you guys agree with Ansca perspective ?
> To unsubscribe, reply using "remove me" as the subject.
Colonial Duty Free Shop
Well, it's easy for them: I believe they're simply collecting the .lua
files, running them through luac, pasting the resulting C code into .c
or .m files, and linking to liblua statically.
If they went the extra mile of obfuscation, they changed the lua_*
prefixes into something else as well. Or, even easier, if liblua is
linked statically it becomes just a matter of stripping symbols.
Wax is not a tool to facilitate cross-platform development; it's
completely built for iPhone, Obj-C and Cocoa. I think it's technically
and spiritually safe. And given the uproar, I'm completely positive
that Apple will cave and re-flexibilise that clause.
For the time being, though, using luac, liblua.a and strip should be enough.
1. I don't think it's really been "allowed" ever since they changed
the interpreted code clause to read "...download or use..." instead of
"...download and use..." or whatever it was. But this hasn't prevented
Wax apps from being accepted.
2. Even though cross-platform development isn't targeted explicitly, I
think it's clear that this is really what Apple cares about.
So it's really just a question of enforcement, and we might be safe if
Apple doesn't see Wax specifically as a threat.
All of these SDK TOS clauses read like so many other outlandish
limitations in just about every EULA for every software product made
in the last 20 years. The difference is that Apple doesn't need their
TOS to hold up in a court of law (they already hold all the power with
the app store), so they can actually implement these extreme measures
Some chin-scratching about the future: my hope at this point is that
the iP* platform becomes *so* popular that continuing with draconian
and anti-competitive rules like this eventually invites an antitrust
suit. IANAL, but a suit like that seems no less plausible to me than
the one against Microsoft for bundling IE in Windows. But that would
hinge on Apple's platform getting a lot more market share.
On Apr 9, 8:21 am, André Braga <andrebr...@gmail.com> wrote:
> To unsubscribe, reply using "remove me" as the subject.
Nothing to see here, move along, move along.
On a purely practical point of view, Lua is safe. It's completely
impossible to think about modern (2000 to 2010) game development without
some form of scripting. This is going to happen either via some DSL
developed in-house, or via a 3rd party scripting language. And among 3rd
party languages, Lua happens to be the most popular for game
development, closely followed by Python.
The difference is that not even the Lua authors share/encourage the
vision that Lua works fine as a stand-alone language, and always present
the language on an embedding scenario.
That said, there is *no* classpath/common runtime library/Python kitchen
sink/Ruby kitchen sink equivalent in the Lua world, so it's rather easy
to argue that Lua is not a stand-alone development tool, but a scripting
library on top of C that happens to provide facilities such as regular
expressions, simple object orientation, closures, garbage collection and
state-of-the-art associative maps.
What's left for argument is whether bridges such as Wax are also safe.
I'd argue that they are, as long as they are fully embedded in the C
code instead of living as shared libraries and interpretable source files.
Now, given Apple's recent usage of automated tools to audit the
binaries, stripping them is a nice idea. Just to play safe.
Seriously Corey, thanks so much for Wax! I'll be really pissed if
Apple rejects it, Wax is so nice. I really do think it would've taken
me 2-3 weeks to get done what I did in 3 days using Wax.
My app will make all it's revenue from iTunes Store affiliate links
(it's an app that scans your library and searches for new albums by
artists you have), and I'm still waiting for my affiliate status as
well, so talk about being fully at the mercy of Cupertino..
Sent from my iPad
Since the iPad just got mentioned on a Section 3.3.1 thread... I've
been ruminating quite a bit over the SDK agreement changes and
everything points to something I've suspected ever since Apple
"adopted" the LLVM project. This is not simply a matter of stalling
Adobe via legalese and whoever else gets affected is but collateral
damage in Apple's war against Flash; this is about deep stuff going on
with OS X that will affect the very future of it, and the computing
platforms it's used on, at the lowest level.
Consider the following scenario:
What if Apple's changes to Section 3.3.1 are only marginally related
to Flash, MonoTouch and other
"let's-circumvent-the-Objective-C-runtime" frameworks/RAD tools.
Notice how the blessed languages match exactly what clang can compile,
I've been saying this for over an year now (and have some emails
posted to public lists to prove it): what's happening here is that
Apple is setting the stage to phase out GCC, leverage the expertise
from the processor design companies they acquired to tune their ASICs
to the compiler and their compiler to exclusive features they'll build
into the ASICs as well (see: they don't call the A4 an ARM processor,
they singled it out -- an otherwise black box component -- as a key
piece of what makes the iPad experience so smooth, and they *really*
control the whole widget now, down to the CPU and toolchain level!),
and push the LLVM bitcode as a platform-neutral binary format. OpenCL
was a strategy to get the HPC/GPU industry behind LLVM, and now Apple
is going to bake the OpenCL ability of seamlessly targeting a number
of processing units inside a computer straight into the (virtual)
machine instruction level.
In other words, Apple is preparing their fifth architectural
transition (68k -> PPC -> Intel -> ARM -> any); as their
desktop/notebook/handheld platforms eventually converge at the
hardware level, there will be a need to change things at the ABI level
to make it all happen, a bunch of things will be deprecated by OS X
10.7, and their veto regarding 3rd party compilers (Adobe's version of
LLVM) and frameworks getting anywhere closer to iPhone OS is Apple's
quite emphatic way of avoiding the CodeWarrior/PowerPlant/Carbon64
situation all over again.
I posit that Apple is going the asymmetric multiprocessing route,
taking the performance-per-Watt benchmark to a whole new level where
every processing unit in the system could be harnessed on demand to
provide computing power to any application, and what they're doing
here, now, with such draconian clauses in their fastest growing
platform's SDKs, is planting the seeds of this revolution at the
software level, while keeping the body count relatively low by giving
developers plenty of time to catch up.
Disclaimer: I'm in no way affiliated to Apple in any capacity other
than using their products for close to 18 years now, nor am I not
privy to any insider information. I'm a Computer Scientist and have
been following the progress of LLVM since way before Apple hired Chris
Lattner, and seeing how all those pieces are falling together this is
the only scenario that makes complete sense to me. Feel free to post
this message to a personal weblog, in part or in its entirety, and if
you do, please be so kind as to mentioning my name and that this was
read on a mailing list, since I don't keep a personal weblog myself.
André, you said, "using luac, liblua.a and strip should be enough."
could you expand on this? Is there a way to submit your app so all
lua is stripped out and it is 100% Objective-C? If someone could post
step by step instructions on how to do this (or if it's possible)
that'd be great.
On Apr 9, 5:21 am, André Braga <andrebr...@gmail.com> wrote:
> André, you said, "using luac, liblua.a and strip should be enough."
> could you expand on this? Is there a way to submit your app so all
> lua is stripped out and it is 100% Objective-C? If someone could post
> step by step instructions on how to do this (or if it's possible)
> that'd be great.
I can't find a doc for 5.x, but here's for 4: http://www.lua.org/manual/4.0/luac.html
It compiles scripts to bytecode, so I personally don't see how this is any more safe than parsing the scripts at runtime. Apple could implement a scanner for bytecode strings embedded in the binary. Then people would obfuscate or randomize the lua bytecode for each app, then Apple would... this is still ridiculous.
> I can't find a doc for 5.x, but here's for 4: http://www.lua.org/manual/4.0/luac.html
In general, too many things changed from Lua 4 to 5.1 to be able to
use Lua 4 docs reliably now. It is better to avoid this.
> It compiles scripts to bytecode, so I personally don't see how this is any more safe than parsing the scripts at runtime. Apple could implement a scanner for bytecode strings embedded in the binary. Then people would obfuscate or randomize the lua bytecode for each app, then Apple would... this is still ridiculous.
That's walking a minefield. You can't tie money and time to such project.
Oops, sorry, not luac, but bin2c (at least I got the "c" part right!)
(bin2c is part of the Lua source code and comes precompiled in the
binary distributions of Lua for Windows)
See http://lua-users.org/wiki/BinToCee and the links at the end for
how to embed the Lua bytecodes of a source file and its required
> It compiles scripts to bytecode, so I personally don't see how this
> is any more safe than parsing the scripts at runtime. Apple could
> implement a scanner for bytecode strings embedded in the binary.
> Then people would obfuscate or randomize the lua bytecode for each
> app, then Apple would... this is still ridiculous.
Then you reach the computationally unfeasible realm of NP-Hard (the
halting problem), for which Apple doesn't have a solution to.
(Nor anybody else, for the matter.)
The possibility of finding binary patterns in the resulting object
files is real.
However, I believe that if you embed the bytecode straight into C and
XOR (or otherwise encrypt/obfuscate) the array to a key of your
liking, there's no way Apple could tell that you embedded a script
there, short of manually disassembling and analysing what's going on.
That takes care of the script part.
Build your own liblua.a and mess with optimisation flags and so on,
then link statically against it and strip your binaries in the end,
and it becomes rather impractical for them to even try to locate
patterns coming from liblua itself.
This sucks and is rather boring to perform, but it works. People have
been doing it ever since the shareware was invented, to obfuscate copy
protection checks and such. A motivated enough cracker will be able to
beat it eventually, but that's not what Apple is doing. Not worth the
> That's walking a minefield. You can't tie money and time to such
Considering that the Corona guys believe they are safe, and there's
nothing they could be doing to "protect" themselves that's different
from what I described above (short of having built a Lua to C
compiler, which, if based upon http://lua-users.org/wiki/LuaToCee
would end up being way too slow to be practical for writing a
performance-sensitive app on the iPhone), I believe Wax is safe as
Honestly, I believe Wax is safe even without those provisions, as I
feel Apple's wording targets fully alien programming environments
where XCode is bypassed on its entirety, which is not the case for
This amounts to endorsement, which is something that Apple WILL NOT
DO. "Don't ask, don't tell" is a smarter strategy.
Besides, your statement that investing time and money on a Wax project
is a liability is false. If you use Lua strictly for scripting, it's
*safe*. You can't go wrong with using Wax as a prototyping tool as
well. The gray area is deploying an app where Wax was used as a bridge
to Obj-C. Apple might reject that. Hence my suggestions to obfuscate
some of the Wax magic in order to stay under the radar.
Seriously guys, stop panicking. Wax does an amazing job as a
prototyping tool. This is nothing different from rewriting your code
for speed. If I had a dime each time I read "rewrote the engine from
scratch" on a changelog...
If Wax saves you from doing that even once (because you have the
chance to experiment and adapt quickly to see what works), YOU PROFIT.
Anyways, no time to look at it tonight.
It's a bitter pill, but clearly one that many of us are willing to
swallow anyway because she is so desirable.