My company has run square into this. The war with Flash is one reason. But the other key reason is that they don’t want other companies setting up independent app stores that could subvert their ability to collect their app tax and manage things like carrier bandwidth usage restrictions. Your code email and download is a first step in that direction whether you intend to complete the journey or not.
The best way to get past the limits is simply to submit to their app store policies and use the in-app purchase feature to get downloadable code and modules. Apple gets their cut of any revenues and you play by the rules and get more or less the features
I discussed this with the app reviewer and he claimed that even typing the code, line-by-line, into the editor from the web could constitute “downloadable code.” However he seemed hesitant to commit to whether that was guaranteed to be against the rules.
He did say that anything that can change the experience after download from the App Store, through executable code (IAP or not), is against the rules. Anything that can export (he used the word “extract”) code from the app is also against the rules.
Yet many times he gave me the example of a scientific calculator, which can be programmed to an extent, as an example of what would be allowed on the store. So this seems like it is a gray area and we will submit a number of proposals to the App Review Board regarding ways to include this feature.
We will make the argument that the app itself does not download code, the user initiates the action, i.e., pushes the .codea file into the app from the web.
We will also suggest making sharing “opt-in” by default, presenting a strongly worded disclaimer, and resorting to various copy and paste solutions.
For now we’ll be submitting the next update as 1.2.7, as it includes more new features (setContext), but will remove the .codea document type.
Apple doesn’t care, and you won’t be happy with it.
it’s like linux, about 5 years ago. it was usable - not pretty. And not a real alternative for windows, unless you were a particular kind of fanatic (like I was, and am). Today - ubuntu is pretty darn usable.
I’d consider an ipad competitor - if such a thing existed. Today, it doesn’t - take all the good of the ipad, and all the bad apple does, and it still stands head and shoulders above the competition. I wish that wasn’t the case - but it is. Fortunately - it won’t be that way forever. I’m not suggesting Apple will disappear tomorrow - Microsoft is still around - but, alas, I suspect the loss of Steve is the beginning of the end - they’ll coast along for a few more years on momentum, and Ives helps… but 10 years from now, they won’t be on top anymore. It’s not going to take forever for the competition to catch on, even google, thick as they are, aren’t that thick. (I love/hate google - they do awesome tech stuff, and don’t have the common sense to recognize what they’re bad at and bring in good people to do it…)
I think Apple wants to allow these sorts of apps, they are just overly cautious regarding security and user experience (perhaps unnecessarily so).
It’s a gray area where one reviewer may interpret things one way, and another in a different way. The system hasn’t been tested enough. Hopefully we can continue discussions with Apple and improve the way this rule is applied.
(I probably would never have been attracted to the iPad if it wasn’t for Apple’s strong control over the end-user experience, so I can’t complain too much about this situation.)
I second the suggestion of sockets. Oh and give me more I/O capability within /Codify/Library. Neight of those seem necessarily offensive to the rules. Not trying to be sneaky about it but if code sharing can’t be part of the app then maybe it’s ok if the app becomes powerful enough for users to do their own sharing schemes on top of it.
Is there anything we can do to help? I could send an email pointing out the educative benefits of being able to share Codea projects - it may be that they’re looking at it as a way of sharing games and haven’t thought about a lecturer wanting theor students to explore something via a little simulation.
I keep wracking my brain for a workaround - I mean, I can do it tethered (mount ipad, copy back and forth), but it’s the untethered “ooh, that’s nice, let’s see how they did that” that’s fun.
Maybe a pragma so that a bunch of tabs can be cut and pasted in a single go? Something like a line that had “-- #TAB: Tabname”, where Codea would see that and make a new tab, then move that code into the tab. You’d still have to cut and paste - but only once. There were things I wanted to look at in the pre-.codea days where I didn’t, simply because I didn’t want to cut and paste 12 tabs.
That would get us down to a single operation at least. Assuming they don’t blow away the ability to paste into the app.
Is there any data sharing available between safari and the rest of iOS, other than “open with”? I’m thinking javascript that could do the select-and-cut operation with a single click. I’ll have to research; if it was “click this link in javascript” (which they can’t do anything about), then run Codea, make a new project, and paste…
I also have this idea involving a RS-232 cable, suction cups, some old medical equipment, and one of those drinking birds, but I think that one needs more work.
Oh… great! The day we have been afraid of is here now!
I think Apple is starting to be cautios about Codea’s code sharing feature more because Codea is getting more attention and popularity. It has been featured on Staff Favorite in App Store for a while. C’mon… everyone will admit that Codea is the best on-iPad coding app. Every techie blogs I know is praising and talking about it.
I think Apple isn’t fair. Many other coding apps have email code sharing feature for ages, even before Codea existed. And they still got the feature now. There’s no sign they got the same notification as Codea. I suspect Apple don’t care about them simply because they’re not as popular as Codea.
Can’t TwoLivesLeft argue with Apple using that fact? Why other app is allowed to have the exact same feature but Codea isn’t? And, as asked by Andrew, is there anything we can do to help? Send email to Apple, made a petition, or something?
Can you name a coding app on the ipad or iphone that allows email import/export? I looked at the lua apps today, and none of them seemed to have it - indeed, one had removed their import at apple’s insistence. Part of me says the same thing - find examples of others doing it - and part of me says that it will just bring apple down on them as well.
Apple told me that those other apps have also “slipped through” the process and should not have those features.
Our plan is to submit 1.2.7 with sharing disabled. Then we will submit 1.2.8 with sharing re-enabled through an opt-in process with a warning. We will also notify Apple of its inclusion. If rejected, we will appeal the decision in an attempt to initiate further discussion.
The emailfile() looks to just send email. I don’t know if web() fetches a web page, or simply launches safari with a given web page - but neither implies code execution.
I am somewhat concerned that sockets and/or wget, along with loadstring(), will be seen in the same light - a way to download and execute code. Perhaps not - the end-user has to put them together. Of course - the end user has to pick a .codea file and choose to launch it in Codea, sigh. We want loadstring() because it makes marshall/unmarshall much easier, but I’d frankly lose it in favor of networking if push came to shove. (We can marshall/unmarshall without loadstring - it’s just cumbersome and ugly).
Although I wouldn’t send an email to anyone without TLL’s okay, the one thing that we can all do which can only help is leave reviews on the App Store. Of course, these shouldn’t mention the sharing but should just say how wonderful this application is and all the different circumstances we can think of using this in (such as education …).
Seriously, I don’t know how important their education commitment is for Apple, but they do talk about it a fair bit on their webpages, and it may be something that hasn’t been associated with Codea in their minds because the examples tend to be game-related and the original description was about prototyping and similar. But I fully intend to use this application in my lectures next semester. I’m converting various animations that I did using processing to Codea and the possibilities are … endless!
Reviews would be great. I love seeing iTunes reviews. It’s certainly what many people use to get an initial opinion of Codea. A lot of initial negative reviews stemmed from the fact that code couldn’t be shared, regardless of whether it was due to policy.
@Bortels setContext - yes, sockets - no (for now). If we included sockets (and loadstring) then we really would have downloadable code. And I don’t want to push our luck at this stage. We will look at including them in the future, though.
Apple is a really big company. So it’s hard for them to curate a consistent, fair, and controlled environment for Apps. We’ll just have to take this up with the more technically minded app reviewers and make our case.
