you cannot legally parse ANY js function and bind it to native code, PERIOD.

I believe NimbleKit is now accepted – as explained by Alexander above.

http://www.apple.com/downloads/macosx/development_tools/nimblekit.html

I took this to be, at the very least, an overall technical affirmation of the tool.

But if Apple is featuring a product that they are then rejecting the use of in practice, that’s ridiculous.

Note: I have 2 NimbleKit projects in production, but have not finished and submitted them yet. So I have neither app acceptance nor rejection experience using NimbleKit. Wish me luck! =)

Non – je travaille pas chez Apple. Je travail chez moi maintenant car je veux faire des choses que je pouvais pas faire a mon dernier boulot.

Ce-que je peut te dire c’est que mon francais est terrible. D’accord? Le francais est pas ma langue maternelle, alors je peux pas m’exprimer en francais comme en anglais.

That is, there might be an issue here with language barriers. It’s hard in English to tell when someone’s angry/joking/etc., and it’s even harder when trying to figure out what someone’s tone is in a language other than your own.

So, I’m not angry

I was just thinking out loud about some of the reasons Apple might not want projects like NimbleKit around. As I stated, I didn’t know much about NimbleKit – just a summary of what it does, and I tried to infer the rest. I should have made it clearer that the issues I was raising had more to do with how a system like NimbleKit *could potentially* be abused (though it appears I misunderstood how NimbleKit works).

I have no problem at all with someone wanting to write their apps using HTML and script. I’m very platform-agnostic. I’ve worked with many platforms and tools – even when I was working at Microsoft, I recommended things like MySQL to customers when I thought it was “the right tool for the job.” I want people to use the tools *they* want to use – I don’t like religious tech battles. However, I can see why you took my posts the way you did, and that was my bad – I didn’t clarify my position.

Apologies, by the way, to Alexander – I didn’t intend to speak poorly of NimbleKit if that’s how it came off.

After reading the summary of NimbleKit, I got to thinking about various approaches to writing such a framework. I’ve looked at some of the others out there, but hadn’t previously thought about the issues beyond what it might be like to use in one of my own projects.

The idea I was enjoying, and one that nobody would be able to get away with, was providing a javascript/Objective-C bridge that would allow you to send arbitrary messages to Objective-C types. If there were such a system, you could get around all kinds of limitations imposed by Apple’s rules (which is, of course, the reason such a system would never see the light of day).

It’d be a way around the no-plugin rule. Want more functionality for your *native* app? Point it to a URL, grab new HTML and script, save it in the Documents folder, and you’ve got a plugin.

Contrary to how I came off in my comment, I actually really *like* that idea. There’s a simplicity to it that I appreciate, though the security holes are obvious. That might be part of the reason Apple was especially strict with NimbleKit – because of how anything-goes Objective-C can be, it’d be easy to slip some code into such a framework that would allow for all kinds of trouble. I’m *not* saying NimbleKit does this – just saying that you *could* do something like this with a javascript/Objective-C pass-through doohickey, and it may be that Apple is being unusually cautious because of it.

The post and comments got me thinking about all sorts of ways you could circumvent the rules about plugins and accessing “private” APIs. It’s interesting stuff. (Interesting stuff, I should add, that’d get any such apps yanked right out of the store.)

I should really shut up at this point – this is all thought-exercise stuff – I’m not advocating breaking the rules – just navel-gazing and daydreaming…

It wouldn’t be *that* easy, but it’d be easier to catch you. Also, because binaries are rigid, there’d only be so much you can do – even if you replaced an existing call with a private API call, your code would have to be written in such a way that whatever happened as a result fit into the app’s existing logic. A clever person could do it, but, except for the thrill of getting your app pulled, I’d like to think a clever person might spend more time writing a *good* app that’s worth the money and that improves everybody’s lives. Even the people without iPhones. Clever people should write apps that turn sound emitted from the phone’s speakers into food. Or that turn dirt into money. Apps that solve financial crises and food shortages – *that’s* what clever people should be doing. Little mobile Bono apps.

Sorry. Got a little tangential there near the end. But wanted to point out that I’m aware there are ways of doing bad, naughty things even with the system as it is. I don’t want to make it sound like the Objective-C runtime is a secure, un-exploitable thing when it totally isn’t (which is what Apple gets for not providing a modern, managed environment for app execution – they compensate with sandboxing, and although it works, it’s a real pain for devs (remember the days when you could share data between apps without resorting to all kinds of nasty hacks? I do. I miss those days.)).

Aight.

Turning off my fingers for now.

Juuust being thorough…

I should read more about NimbleKit, but like any idiot on the net, I want to have my say before I sufficiently research it (at least I admit it, right?).

So, here’s what I think Apple’s beef actually is…

When you submit your app, what it is is what it’s gonna be. Your binary is your binary, and your code isn’t going to change. Even with the new in-app purchase functionality that lets you turn your “lite” version into the full version with a payment, the full code for the full version was in the lite version to begin with – paying just unlocks the extra features.

It *looks* like a plugin system, but it isn’t. And if anything new is pulled down to your phone as a result of an in-app purchase, it’s something that’s also gone through The Process (you can’t just download any old thing – and if you figure out how to, Apple would boot you).

Hang on – this gets relevant.

The difference here is that it *almost* sounds like you can put together some html and script where your script calls are passed through to Objective-C objects.

While the NimbleKit-based app you write might be totally legit at the time you submit it, there’s a potential hole here: unlike your app’s binary, which is what it is and all it will ever be, your app could easily pull new html and script from some site of your choosing, store it locally on the phone, and contain script that passes an entirely different set of calls to the Objective-C end of things.

That is, with a single call (if you wanted to do it the uncool synchronous way), your app could pull down what would be the equivalent of a plugin. It’s just that the plugin would be written using script hosted in an html page rather than in a native binary that hooks into your original binary and provides additional functionality.

If I’m still not making sense, it sounds to me (and I could be TOTALLY wrong here) like NimbleKit *could* allow you to pass arbitrary calls to arbitrary objects. It’s easy enough to call “performSelector:” on an object. You do it all the time in the Objective-C world as a way of implementing callbacks (and exactly one-bajillion other things).

If you could use NimbleKit to call “performSelector:” on an object, you could easily access private APIs through your script. And, like I said, although the script that ships with your app might be legit, if NimbleKit allows for this, it would be eeeeeasy to call all sorts of things you aren’t supposed to call just by downloading a new script that contains the calls that get passed through to Objective-C-land.

You have your fun NimbleKit-based Pac-Man clone (or whatever), and the AppStore people get a kick out of it, and they delay approving other apps because they’re so busy playing your really fun Pac-Man clone, but then it dawns on them that “performSelector:” is getting called by the pass-through mechanism, and that any old html document could be downloaded and stored in the app’s sandboxed Documents folder. From there, it’d be easy enough for your app to load that page, run that script, and then everything goes horribly wrong because your *new* script goes to town on private APIs.

Again, I want to stress that I don’t know if this is how NimbleKit works, but if it does have a pass-through system that lets you call Objective-C from javascript (and it’s not remotely the first tool to let you do that), if there isn’t some degree of protection from some very bad and naughty person taking advantage of Objective-C’s partially dynamic nature, then Apple is right to reject it.

While I’m babbling, you wouldn’t even have to download a new page and run it locally – you could point a UIWebView instance to the URL for the page and start executing away as soon as it loads.

If I were Apple, I’d reject anything that even remotely came close to allowing for that. While it *might* really come down to a matter of naming of methods (which seems unlikely, but, as I admitted, I haven’t looked into this enough), then the problem is easily fixed and everybody’s happy. And anybody with a text editor (or, I don’t know, IDE) should only be slightly inconvenienced by having to perform a search and replace on the method names.

In short, this could potentially have been very bad for Apple (We approve this app! Hey, this app just hit a page that has new script that gets calls passed through to private APIs! Hey… this stinks!), and what they’re asking isn’t unreasonable, and the developer’s rant in his forums is pretty whiny, which makes me less sympathetic to him (OMG, everybody… whoah is us… we’re going to have to search and replace some functions and resubmit… what’s the world coming to… ohhhh… whoah is us… (there’s some paraphrasing in there)).

Much of the time, people get their apps rejected because they violate rules set out in the guidelines that, as an iPhone dev, you *must* read. But I’ve met so many devs who haven’t read the first line – they sit down, start copying and pasting code they find on the web, put together their million-dollar idea, wait for the bucks to roll in, and then get rejected because their apps suck or violate Apple’s rules.

In this case, it sounds like NimbleKit could be modified to perform its function without also being a risk.

If I were Apple, and if I’m even half-right about what I’ve said here, I’d reject that sucker, too.