All are good points, but number 2 is the big one for me. That was my first thought when I heard what Apple was doing, and I think it's important to keep that in consideration. While I don't always agree with DHH, he makes some good, rational points here. It should be noted that most of these arguments have been made elsewhere, but it's a great summation.
It's fascinating. This is the way I look at them, as being on the side of people who agree with Apple on this one.
#1: Don't agree. Apple has 180,000 apps in their App store, maybe a good time to remove incentives for a new influx of non-programmer-written apps straight from Flash? Oh, they're getting rid of other stuff that also encourages people to use other tools than their own? I think they can live with that.
#2: They're not. Tell me where and when Apple said: "You will be able to develop for the iPhone using any and all tools of your choosing." They didn't. They're simply clarifying what's been their position all along, that XCode/Cocoa is the environment in which you create iPhone apps. Sure, other stuff have been able to sneak in stuff, but hardly with an Apple seal of approval. If you're using one of those tools without a suspicion Apple might not like it even before this, I'd say you're a bit naive.
#3: Irrelevant. Apple has told developers which tools they can use from the get-go. I imagine the existing cross-platform products have been too small to have been a priority, but here comes Adobe with something that creates iPhone apps straight from the desk of a designer. Yes, did you see the CS5 presentation? "Create iPhone apps without writing any code!" Sounds like great apps to me.
#4: Of course it's unfair. But there isn't any better way to enforce their rules. Naturally there'll be apps that fall through the cracks. But a "Aw, why can't I when that app could?" whine sounds very 7-year-old to me. They're putting up rules, if you follow them you should be fine. If someone does something that might be within the rules, but they're not sure, they might get rejected. If someone else tries the same thing, they might get rejected, regardless of whether the first guy was caught or not.
#5: Not sure this ia a very good argument either. For me, I develop for Apple products because I love the platform, and I think there are quite a lot of other apps that have been hanging around with Apple because we feel that is the best platform in the world. Not perfect, but best. And I like it when Apple says that what we've learned during the years of sticking by the company because of that conviction, rather than some sense of duty, is going to pay off. Sure, Apple could release the platform to any and all languages out there, implement C#, Java and whatever else might be popular right now. But that would seem to me to cater to the populist crowd, rather than the faithful, so to speak. And those programmers are the same programmers that will move away from the platform when something else catches their fancy. I think Apple wants people like Omni Group rather than the "Oh, lord, another device, another language, who cares? I guess I'll _have_ to learn it, then."-crowd.
What you've said there is that you are not rational with respect to your position re Apple. You explicitly say that people should work with Apple platform from a "sense of duty", that people should be "faithful".
This seems to me to make you unqualified to counter rational arguments.
Hm, nope. I'm explicitly saying work with Apple stuff out of conviction, rather than a sense of duty.
And I'm saying that Apple has a point in supporting the faithful, as in the people who are convinced this platform is the one they want to work with, because that group of programmers will probably stick around even when some new other thing comes around.
I don't have time to respond to each point, but I will say that it's well thought out. I don't agree with many points, but you've clearly thought about it. =)
"They're putting up rules, if you follow them you should be fine."
The big issue is that they are changing rules. They are. There isn't anything you can say that changes this. So even if you did follow the rules, you are still stuck with an unsure situation.
They're undoubtedly changing the language in the developer TOS, that is of course undisputable. =)
However, when introducing the iPhone SDK, they clearly said (about XCode) "This is where you'll be developing all your apps." I'm saying you could consider this a change in legal language to more clearly adhere to the spirit of the premises of that SDK.
The fact that people have been able to use products in a grey area to sidestep this, doesn't mean that the rules have been changed, just that they haven't been enforced before. Apple never said: You can develop in any IDE you want for the iPhone, and then changed their mind again. None of these tools that are affected have been approved as developer tools by Apple before, and people using them know or should have known that.
What has happened is that Apple is starting to clearly stress that Xcode is the only approved developer tool. The major change is that unapproved tools now clearly are marked as unapproved, which in itself isn't a change from before. They've always been unapproved.
Now, as far as enforcement, that might be just the same as before, since we haven't seen any rejections based on the new policy. Most people, including me, seems to be guessing on that this will mean some kind of enforcement as well, but we're just going to have to see what's going on there. Either way, if you've been using Apple approved development tools before this change, nothing has changed, and therefore there is nothing more to worry about after than before this change in stance.
"Either way, if you've been using Apple approved development tools before this change, nothing has changed, and therefore there is nothing more to worry about after than before this change in stance."
That's one way to look at it. Of course, then the question becomes one of a permissive development platform. You are only allowed to use what they say you can, and if they don't say you can use it, you shouldn't. And even then, they've proven in the past that even this isn't reliable. You can follow their rules, and it still not matter.
This isn't the first time they've done this. Just because they say you can do something now doesn't mean they won't pull the plug later. This is a volatile situation to be in. Now, I won't argue whether they can do it legally. Nor will I suggest that other companies can't do it. But Apple seems to be rather blatant about it.
Absolutely, I do agree this question is about a permissive development platform. And that's the whole point, I think.
As for the second points, I don't recognize what you're describing. What I can say is that I don't consider letting an app through into the App store itself is a seal of approval for whatever technique or tool that app is using, but rather a sign that they're not checking for whatever it is they're doing. If other apps get rejected for stuff others have been accepted for, or even earlier versions have been accepted for, that's a refinement of the approval process to me.
And yes, to some that might feel like a volatile situation. I'm suggesting that non-controversial app development (as in using approved tools, not writing apps that are in a grey zone when it comes to what they approve, and not using private APIs) is cutting down on that volatility in a big way, wouldn't you agree?
I concede that I might have missed your point totally, but since you're not giving examples I'm looking forward to a more verbose rebuttal in that case. =)
