Section 3.3.1 change
zza jin
Program License Agreement
Here is John Gruber's take on it -
http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
--
Subscription settings: http://groups.google.com/group/iphonewax/subscribe?hl=en
corey johnson
good way – this is total bullshit. I used to admire Apple, but there
is not technical/logical reason for them to insert this language into
the TOS. Hopefully Wax will fly under the radar though!
Grzegorz Adam Hankiewicz
El 09/04/2010, a las 00:43, corey johnson escribió:
> I was going to try and phrase this politely but I can't think of a
> good way – this is total bullshit. I used to admire Apple, but there
> is not technical/logical reason for them to insert this language into
> the TOS. Hopefully Wax will fly under the radar though!
Alexander Gladysh
<gra...@titanium.sabren.com> wrote:
> El 09/04/2010, a las 00:43, corey johnson escribió:
>> I was going to try and phrase this politely but I can't think of a
>> good way – this is total bullshit. I used to admire Apple, but there
>> is not technical/logical reason for them to insert this language into
>> the TOS.
> Hopefully Wax will fly under the radar though!
are explicitly banned from the iPhone.
Anyone who uses anything else is risking rejection. I think this could
be worked around by hiding Lua sources in the executable, but that is
not the bullet proof solution.
> I hope the final 4.0 sdk is clear on this and also states the kind of clothes we have to be wearing while programming. Probably jeans and turtleneck.
you accept them, not when 4.0 is released.
And if you do not accept the changes before 22th April, you can't use
the provisioning portal.
This all is very sad. :-(
Alexander.
Ryan
Jeesh. Apple, why? Figures, I'm almost done with my app (that I
started on Tuesday), it'll take at least a week or two to transpose it
all to Obj-C (especially the wax.http.request stuff).
I for one will still submit with Wax and see what happens.
Ryan
corey johnson
Grzegorz Adam Hankiewicz
The app I have on the store now uses snprintf, since it's half written in plain old C. I wonder if I'll be banned from updating it at all with the "new regime".
Alexander Gladysh
<gra...@titanium.sabren.com> wrote:
> Even if the license was not in place, has anybody read the Appcelerator blog entry http://developer.appcelerator.com/blog/2010/03/the-apple-rejection-economy-and-therapy.html? It talks about an app being rejected for using sprintf/strncopy.
> The app I have on the store now uses snprintf, since it's half written in plain old C. I wonder if I'll be banned from updating it at all with the "new regime".
That's insane.
Alexander.
corey johnson
Alexander Gladysh
> Possibly good news?
> http://developer.appcelerator.com/blog/2010/04/iphone-os-4-0-announcement-and-our-commitment-to-you.html
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.
Alexander.
Federico Brubacher
in the developer machine and their binaries are pure Obj-c , Wax
wouldn't fall into this category afik,
http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/
Do you guys agree with Ansca perspective ?
Fede
> --
> To unsubscribe, reply using "remove me" as the subject.
>
--
Federico Brubacher
fbrubacher.github.com
Colonial Duty Free Shop
www.colonial.com.uy
André Braga
> Ansca is saying that they are safe because they do all the compilation
> in the developer machine and their binaries are pure Obj-c , Wax
> wouldn't fall into this category afik,
> http://blog.anscamobile.com/2010/04/do-apples-new-rules-affect-you/
> Do you guys agree with Ansca perspective ?
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.
Cheers,
A.
James MacAulay
it's written, it seems clear that Wax is simply "not allowed." On the
other hand, two things:
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
without recourse.
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.
-James
On Apr 9, 8:21 am, André Braga <andrebr...@gmail.com> wrote:
Lars Ræder
that the majority of support calls for Safari crashing is due to bugs
in Flash that Adobe haven't fixed in a long time. I can see how they'd
want to restrict the number of languages being used for development to
a few that they can reasonably provide support for. While I think it's
a stupid approach in a time of user forums, I can follow their
reasoning. I just don't like it.
-Lars
> --
> To unsubscribe, reply using "remove me" as the subject.
>
--
Nothing to see here, move along, move along.
André Braga
> 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.
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.
Ryan
Alright, app submitted. Here goes nothing!
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..
Thanks,
Ryan
Corey
Sent from my iPad
André Braga
> Keep us updated on the status Ryan!
>
> Sent from my iPad
Nice :)
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,
except for Javascript which is handled by Nitro.
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.
Cheers,
A.
Andrew Arrow
let wax live.
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:
Grzegorz Adam Hankiewicz
El 10/04/2010, a las 19:43, Andrew Arrow escribió:
> 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.
Alexander Gladysh
>> 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
http://www.lua.org/manual/5.1/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.
Alexander.
André Braga
> 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.
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
modules.
> 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
trouble.
> That's walking a minefield. You can't tie money and time to such
> project
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
well.
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
Wax.
Cheers,
A.
Andrew Arrow
with 100% certainty that are apps are okay right? We'll always be in
this limbo state of waiting for apple to say no. Makes it really hard
to keep investing time and money into a wax project. Maybe not? Has
anyone asked apple? Could we get an official yes/no answer on wax vs.
just hoping?
André Braga
> But apple will never give us an "all clear" on wax and let us code
> with 100% certainty that are apps are okay right? We'll always be in
> this limbo state of waiting for apple to say no. Makes it really hard
> to keep investing time and money into a wax project. Maybe not? Has
> anyone asked apple? Could we get an official yes/no answer on wax vs.
> just hoping?
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.
Cheers,
A.
Ryan
So bad news is my app was rejected. But good news is it was rejected
because of a crash on startup issue (no idea why..). 3.3.1 wasnt
mentioned at all yet. I'll get them a new build tonight.
Hang tight,
Ryan
Ryan
Hmm, looks like I'll need to figure out the runSelectorInBackground
stuff, my app isn't crashing, just taking longer than 20s to start up
on a non-GS, I suspect it's all the wax.http.request calls I'm making
in viewDidLoad.
Anyways, no time to look at it tonight.
Ryan
corey johnson
the http calls in a background thread and run the callback method when
it gets a response.
Sean Puckett
satisfies end-user requirements there is no rational need for the
first party (developer) or the second party (end-user) to redevelop it
in Obj-C. No need, that is, not imposed by the third party (Apple),
who neither develops the app nor benefits from its development except
by being the gatekeeper to the platform. It is like trying to date a
beautiful woman whose father insists you court her entirely in German,
despite the fact that both you and she are fluent in French.
It's a bitter pill, but clearly one that many of us are willing to
swallow anyway because she is so desirable.
Ryan
Yeah, that's what I'm using. However, I do a REST call for every
Artist the user has in their library, which on my iPhone is like 90.
It seems that just starting each http.request has some overhead. But
the good news is that selectors are working fine now that I'm using a
recent version of Wax, so just moving all that stuff into a
performSelector:withObject:afterDelay allows viewDidLoad to return
quickly now. And I'm mixing in a little AlertView with activity
spinner from Erica Sadun's book, so the overall look and feel is much
better.
Should be able to resubmit tonight.
Thanks,
Ryan
Ryan
Oops, actually it's MPMediaQuery that's insanely slow and blocking up
my run loop. Looks like I need to run that on a background thread.
Brad Parks
here's an example I found awhile ago of how to put a task in a
background thread... It's an Objective C example, but I think it'd be
pretty easy to switch into wax....
http://www.cocos2d-iphone.org/forum/topic/2242#post-29174
Benjamin Tolputt
Given the threaded code I use is all the "intensive" stuff, I tend to use Obj-C & C/C++ code for the threaded functions. Wax is only for the UI in my code.
Ryan
I added a loading UIAlertView (with a UIActivityIndicator instead of a
button, as per Erica's book) and just use
performSelector:withObject:afterDelay to run the MPMediaQuery, that
did the trick (I don't have anything else I can really do until the
query returns in this version, but will need to move some of that to
ObjC for threading in 2.0).
Submitted on Wednesday night, so hopefully will hear back soon.
On Apr 16, 6:12 pm, Benjamin Tolputt <bent.soluti...@gmail.com> wrote:
> My understanding of Wax is that you need to keep all Lua code in the same
> thread. That is, Lua is not thread-safe within the same state (however, you
>
> Given the threaded code I use is all the "intensive" stuff, I tend to use
> Obj-C & C/C++ code for the threaded functions. Wax is only for the UI in my
> code.
>
Ryan
free) http://j.mp/bn1Zy1 Will be submitting 1.1 with more features
this week. I made no attempt to hide that I was using Wax, but never
explicitly called it out either.
Thanks again Corey, I never would've bothered to code it ip without
Wax!
Ryan
corey johnson
Grzegorz Adam Hankiewicz
El 20/04/2010, a las 22:01, Ryan escribió:
> Sweet, my Wax app, NewAlbums, was approved! ITunes link (it's
> free) http://j.mp/bn1Zy1 Will be submitting 1.1 with more features
> this week. I made no attempt to hide that I was using Wax, but never
> explicitly called it out either.
Ah, while typing this the app finally loaded. I think the app will benefit from having a similar interface to the ipod app: tab bars below to categorize by artist/song/year and a search box on the top.
Good work! Now, if it had some cache or something to avoid rescanning stuff. You could md5 the list of songs, and if it didn't change in a day or two, don't download everything again.
Sean Puckett
of my front-line application (Paintbook) because PB is such a key part
of my offerings I must reduce my exposure to rejection as much as
possible. I wound up using a UIWebView with some interesting
javascript hacks to do what I wanted to use Wax for. It's not ideal
but they can't turn me down for it.
I am going to revisit wax with a new application that isn't so
critical to my rev stream shortly!
On Apr 20, 4:01 pm, Ryan <ryanleeschnei...@gmail.com> wrote:
> Sweet, my Wax app, NewAlbums, was approved! ITunes link (it's
Ryan
port to ObjC before doing all that. :)
I'll need to find a work-around for MPMediaQuery. Asking for all the
user's albums is slooow (3 minutes+ on first gen hardware) and no
progress callbacks. Now that I can keep working in Lua I'll experiment
with alternative queries.
Thanks,
Ryan
On Apr 21, 12:37 am, Grzegorz Adam Hankiewicz
> El 20/04/2010, a las 22:01, Ryan escribió:
>
> > Sweet, my Wax app, NewAlbums, was approved! ITunes link (it's