C4 Developer Conference Canned Due to Discontent Over Apple Policies

| News

Jonathan Rentzsch, the organizer of the independent Mac and iPhone developer conference, has canceled the event due to Mr. Rentzsch’s discontent with both Apple’s developer policies and the lack of reaction to those policies from the broader developer community.

In particular, Mr. Rentzsch took issue to Section 3.3.1 of Apple’s iPhone OS developer agreement, which limit developers to using developer tools that meet strict requirements set by Apple.

In an open letter posted to his site, Mr. Rentzsch said that he was drawn to developing for the Mac, and by extension, in part because of the “maniacal focus” Mac developers had for making a great user experience. Such a focus rang true with his own goals as a developer, but he also wanted to push for better “bottom-up” developer tools that allowed developers to do more.

Which is why he started the C4 Conference. In his open letter, he wrote, “I believed the best way to move software forward was to inform Apple programmers about better ways to build software — to infect the best top-downer minds with fertile discontent. My hope was that developers would care primarily about user experience yet also be passionate about utilizing lingual and tooling advances.”

C4, therefore, was his attempt, “to push on the Apple community from the bottom-up.”

The problem with section 3.3.1, according to Mr. Rentzsch, is that Apple has been slow to innovate when it comes to software engineering. “Apple is crazy-innovative in terms of hardware and software design,” he wrote, “but I can count the total number of software engineering advances they’ve made on one hand.”

By limiting developers to the choice of tools they can use, he believes innovation will be artificially retarded, but even that wasn’t the only factor that lead him to cancelling the conference. “By itself Section 3.3.1 wasn’t enough to cause me to quit C4,” he wrote. “I’ve weathered Apple lying to me and their never-ending series of autocratic App Store shenanigans.”

He continued, “But unlike previous issues such as the senseless iPhone SDK NDA, the majority of the community isn’t riled by 3.3.1. On this issue, Apple apologists have the loudest voice. They offer soothing, distracting yet fundamentally irrelevant counterpoints to Apple’s naked power-grab.”

“With resistance to Section 3.3.1 so scattershot and meek,” he wrote, “it’s become clear that I haven’t made the impact I wanted with C4. It’s also clear my interests and the Apple programming community’s interests are farther apart than I had hoped.”

Mr. Rentzsch’s reaction to Section 3.3.1 is likely the highest profile defection away from iPhone OS development sparked by Section 3.3.1. As he noted in his letter, the vast majority of developers, bloggers, and Apple fans have rallied behind Apple in its effort to control development on its smartphone and tablet platforms, a move that was particularly aimed at killing Flash development that was then ported to iPhone OS.

Comments

Bosco (Brad Hutchings)

The saddest thing about 3.3.1 is hearing people who should know better claiming that apps written in Objective-C directly to Apple’s SDK are somehow “better”. It’s comical when the fanboys like Gruber and his repeaters do it.

Rentzsch brings up a great point about Mac developers generally being devoted to great user experience. 95% of that devotion is looking at the whole of the interface, not blindly following guidelines.

Reading him lately, he seems to be where I was a few months ago… He knows this stuff is just wrong, and looking around to see if other smart people realize it yet. And he’s discouraged that others either don’t see it or are purposely ignoring it. The thing is though, that Apple’s policies are at odds with reality. While customers and partners might not be vocal with their mouths or their pens, they will be vocal with their feet. I’m surprised that Android achieved sales parity in the US so quickly. But that just reflects the new reality that Apple is creating.

Bryan Chaffin

Brad, where we continue to be at odds is at this fundamental beginning: Apple’s approach isn’t “wrong,” it’s just wrong for some people.

For other people - a LARGE and profitable number of people - Apple’s approach results in the kind of experience they want.

This is obvious in the sales, and it should be obvious in the number of iPhone apps on the App Store. It is also reflected by the fact that Apple commands the monster share of mobile app sales, despite having a minority share of the handset market.

These are three incontrovertible pieces of evidence that should prove to any rational observer that Apple’s approach is resonating with a portion of the market place.

You (or Ted Landau or Mr. Rentzsch, three people I have a lot of respect for) preferring a less-controlled device/platform does not necessarily mean that Apple’s model is flawed or objectively wrong. It just means that it’s not for you.

In the meanwhile, consumers are voting with their wallets by buying Macs, iPhones, and a new class of tablet device called the iPad in record numbers.

This directly refutes your main assertion.

I’m working on a piece, BTW, on Android vs. iPhone sales.  I hope to run it Thursday.

computerbandgeek

Bryan,

In theory, your argument is true. However, there are lines that need to be drawn. It is ABSOLUTELY wrong, in any sense of the word, to censor people’s right to reasonably free speech, and engaging in anticompetitive behavior. Not allowing people to criticize public figures on one’s platform is most certainly wrong. Blocking services from specific rival companies (such as Google Voice) without even outright admitting it, is just as legally and morally wrong for a completely different set of reasons.

It’s things like this that many of us so upset with Apple’s draconian bullying behavior.

Nemo

Mr. Rentzsch reminds me of Bosco:  He declared a revolution, but no one showed up.  Perhaps it is because the vast majority developers disagree and might even be right in their disagreement.  Well, I know at least one revolutionary that Mr. Rentzsch can count on:  Bosco.  The two of them can storm Apple’s Cupertino campus and hold a sit-in in Steve Jobs’ office.

As for NPD’s sales figures, it amounts to sample size of 150,000.00 from a population of smartphone purchasers that numbered at least 10 million for the quarter in the U.S. alone.  Before I’d declare victory on those numbers, I’d want to know a few things, such as:  (1) What hypothesis defined the population; what was the hypothesis; provide the mean, median, mode, and standard error of measurement for the sample; provides the research protocols for the sampling techniques that obtained a typical and random sample; what questions were members of the sample asked; how many members of the target sample responded; what protocols did the questioners use to collect the data; and given, such a small sample size, was the distribution a normal distribution.  Most of these “statistical” studies that are published in the popular media dont’ provided the foregoing information or, when they do, they don’t hold up to mathematical rigorous standards.  The NPD study hasn’t provide any of this information.

And then there is the context.  The U.S. is an unusual market in that there are really only few viable carriers that Apple can turn two to support the iPhone:  Verizon, AT&T, and perhaps, Sprint.  AT&T has well documented problems.  And I suspect that Apple has had trouble getting to a deal with Verizon.  However, in the wider world, where Apple has, for the most part, been able to adopt a multiple carrier strategy, the iPhone is kicking Android’s butt, no matter whose stats you use.  If Apple does strike a deal with Verizon, Android’s dubious parity with sales of Apple’s iPhone would disappear rather quickly, because it seems that Verizon’s customers are pining for iPhones.  See http://www.eweek.com/c/a/Mobile-and-Wireless/Verizon-Customers-Suffer-from-iPhone-Jealousy-Says-Survey-784099/. 

And that innovation in software tools the Mr. Rentzsch finds wanting in Apple could be just around the corner, as it appears that Apple has been quietly working on a set of open-source tools for RIAs that match, if not exceeds the functionality of Flash, AIR, and Silverlight.  It seems that Apple, unlike Adobe, has that quality that President Lincoln wished for in his generals:  It doesn’t cackle before the egg is laid.  See http://www.appleinsider.com/articles/10/05/07/apple_developing_flash_alternative_named_gianduia.html.

Just think of it Bosco:  new tools for you that are open-source, powerful, and no royalty to Adobe required.  The tools appear to be interoperable with other open-source RIA SDKs, which Flash, AIR, and Silverlight aren’t.  And being open-sourced and interoperable, Apple’s Gianduia tools will let you write for the iPhone and for other platforms with rewrites need only for the Apple specific APIs.  If developers find this Gianduia to be sweet—and given the foregoing, why wouldn’t they?—they will be gobbling up Apple’s Gianduia. 

Of course Bosco, there are downsides.  If the AppleInsider is correct in its reporting and inferences, they won’t be even a whiff of an antitrust case for the U.S. Government, and there won’t be much reason or need for a revolution.

“Say you’re gonna have a revolution . . . .”

Bosco (Brad Hutchings)

Bryan,

The effectiveness of Apple’s development policies will be born out with time. While they present real barriers to market participants making decisions now, they weigh against exit costs and transition costs. Your typical iPhone user isn’t going to ditch her iPhone mid-contract.

But there are some things in the debate which are objectively wrong, as Rentzsch points out. It is incorrect to assert that applications made with third party tools and languages are worse than apps made with Objective-C and Xcode. People can spread that meme through ignorance of the technical issues or just do it deliberately, presumably for some advantage. Either way doesn’t make it right.

You can’t say Rentzch is being dishonest or disingenuous. He is a mensch and just one of the truly good guys in Mac development circles going back more than a decade that I’ve known of him. You can’t say the same about Steve Jobs or Apple PR in general, as Rentzch links. They have a track record of lying about the reasons. It’s no surprise they continue to do so. It is a surprise that longtime Apple fans who know better don’t hold them accountable.

——-
@Nemo: You, more than anyone here, actually make it fun to watch Apple start to flounder. Reminds me of a kid I grew up with who taunted me for years as Notre Dame beat USC. I get to do the taunting now. My day will come on the Apple front, sooner than you think grin.

Nemo

Dear Bosco:  You’ve mischaracterized the argument to say that all apps made with Translators will be bad, while the iPhone SDK will be great, so that if there are some mediocre or bad apps or even one such app made with the iPhone’s SDK or great apps made with a Translator, the argument is false.  But that is not the argument.  The actual argument has two aspects:  First, because Translators don’t and indeed can’t support the latest and uniques features of any unique OSs, they must settle on a set of functionality common to all those OSs to support, which leaves out much of what an innovative company, like Apple, will do to enhance the capabilities its particular OS.  For developers that means the Translators put a ceiling on what can de done, even though what is done might be very good.  Apple insist that that ceiling be removed so that its developers can, if the have the talent and desire, fully exploit the qualities of the iPhone OS to routinely produce great apps.

The second aspect of the argument flows from the first.  By eliminating Translators and freeing developers to discover and exploit the full features of the iPhone OS, several forces operate to significantly increase the likelihood that they will produce better software than they would with a Translator.  One such force is competition:  A crappy app is an opportunity for the expert in the iPhone OS, who can fully exploit that OS—because he isn’t restricted to the limited functions of a Translator—to make a much better app that will defeat the crappy app in the market.  Another force is pride in one’s work:  If you are an expert in the iPhone OS and if there is no Translator to hold you back, your pride in your work will drive you to exploit the iPhone OS to the fullest extent of your ability.  And another force is the iPhone’s SDK itself, which helps even a weak developer, who becomes reasonably proficient in its use, to produce better apps, because its built in features lead to better design for the iPhone OS and a fuller exploitation of the iPhone OS’s features that can happen with a Translator, which is made to produce an app that will run acceptably well everywhere but exceptionally well nowhere.

So, notwithstanding the use of the iPhone SDK or the use of Apple’s prescribed open-source tools, you can produce a mediocre or bad app; you are just significantly less likely to do so.  While you can, notwithstanding the limits of a Translator, use a Translator to produce a good app, you are just significantly less likely to do so.  Apple’s Section 3.3.1 is Apple’s effort to increase the odds of better apps and, thus, a better user’s experience, while decreasing the odds of bad and mediocre apps that lead to a bad user’s experience.

However, there is one point to be made for developers who use Translators, if not for Translators themselves:  To produce a great app using a Translator, you have to be a better developer, because you have less to work with.

Mark Hernandez

After reading Rentzsch’s post a number of times, I find it confusing.  First of all, he should have been more detailed and help educate us with some important details on what he sees that we should all know, but he didn’t, or at least link to where he does.

The implications of section 3.3.1 have been discussed widely now by many smart people and they’re well understood, but I don’t understand how it impacts the C4 conference.  It would have been great to get an explanation.  Until then, I can only assume that Rentzsch is confused and pissed off about something else.

Also, 3.3.1 relates to mobile development, and how much of C4 focuses on iPhone OS?

I’d also like to know what Rentzsch thinks about the current state of tools and languages.  What’s missing? What are the deficiencies?  To use his own argument, do we really need another way to do the same TASK that hasn’t changed over decades either? 

Maybe what’s needed to help advance things forward is something else, like better information management (which is something I see very clearly in particular.)  And better communication and collaboration tools.

Rentzsch’s blog post is a statement is that he is closing the CONFERENCE.  So I’m still wondering what his disappointments with Apple have to do with running a conference? 

CHANGE AND ADAPT

This all sounds to me like it boils down to more a matter of understanding changing times and adapting to them.  And Bryan’s points are right on the money as well.  If we are going to be a pilot fish to Apple’s shark, then we have to move with it when the shark changes direction, as we move forward into new times and places as well.

Furthermore, here’s one big thing going on that I think is SO OBVIOUS that it may be the root of what is happening with Rentzsch…

NEW WAYS OF INTERACTING

The tiny conference is dead.  Online forums are dead and completely worthless (I know because i am a co-administrator of iPhoneDevForums.com).  Real-time conferences and “webinars” are dead.  They’re all anachronisms.  For example, Apple isn’t interested in MacWorld when it can have much of what it provides daily in it’s popular Apple Stores.

And in this case, the conference is dead in particular because it only provides access to a privileged few.

Look, it’s now 2010.  We each have multiple contact points with the internet - in our pocket, on a tablet and on multiple screens around us.  Shouldn’t we be attending the C4 conference on those devices?

Even the WWDC conference is so wrong, only allowing the privileged few to attend, who must have the time, the money and the ability to travel the distance in order to participate, not to mention being fast on the order button.  And what if your need for attending such a conference comes along a month later?  Why should you wait another year?

The only thing that makes WWDC okay is that Apple brings 1,000 engineers to it, and then makes ALL of the session videos available to everyone planet-wide just a couple weeks later, undoing most of the “privileged few” problem.

And as far as communicating goes, here we are, in this blog’s comment section explaining to Rentzsch what he really needs to be thinking about and he is isolated from it.  He certainly won’t read these comments and he doesn’t allow commenting on his blog. 

See how screwed up the interaction is?

THAT is what needs to be fixed.  Not the tools, not the languages. 

Fix the part where a great quantity of the right people can easily participate, develop consensus and work together to work for change.  Those existing tools are old and broken.  Forums are unfocused “rooms with everyone talking at once” with no ability to develop consensus.

But having a tiny conference like C4 that only a few can attend is an idea that is now a thing of the past.  Isn’t that the real problem here?

Mark Hernandez
The Information Workshop

Mark Hernandez

And this whole interaction HERE of…

Static unchangeable blog statement

followed by

Dynamic, reasoned and educated discussion that follows which illuminates the complexity of the statement

...format is messed up too.  It assumes the original statement is infallible, when 99 times out of 100 it needs to be updated after everyone “illuminates” what the original blog post really should be stating.

Our tools are screwed up.  We’re trying to educate each other and develop consensus and the way we are doing it is all wrong.

But we live with it, and don’t (won’t) even notice how bad it is, because we have no power to change it.

Mark

Mark Hernandez

If we could change things, we might agree the title should be…

C4 Developer Conference Canned Due to Conference Format Becoming Obsolete

Bosco (Brad Hutchings)

First, because Translators don?t and indeed can?t support the latest and uniques features of any unique OSs, they must settle on a set of functionality common to all those OSs to support, which leaves out much of what an innovative company, like Apple, will do to enhance the capabilities its particular OS.

Nemo, this contention is incorrect. REAL Studio, for example, supports “plugins” and “declares”. A popular plugin, the MonkeyBread plugin, has provided hooks into Cocoa for years, supporting many of the features that purists seem to think Mac apps must have these days. A popular “declare” library by former REAL Software engineer Aaron Ballman makes it easy to do similar platform-specific things with Windows.

Your second point simply flows from the lie you parrot in the first. You’re an attorney with obviously little/none formal training or experience in software development. So it’s excusable that you’re not familiar with any real counter-examples to the lies you parrot. But intellectual honesty demands that you do something to reconcile the facts with your position once you become aware of the facts. That’s all.

Mikuro

For other people - a LARGE and profitable number of people - Apple?s approach results in the kind of experience they want.

This is obvious in the sales, and it should be obvious in the number of iPhone apps on the App Store.

I don’t think it’s solid reasoning to point to Apple’s market success as evidence that Section 3.3.1 is good for anybody. First of all, 3.3.1 is very new; most of Apple’s success came before it. Secondly, the effects of 3.3.1 will be mostly long-term. Today there’s very little difference in practice between the iPhone as it is and the iPhone as it would be in a hypothetical world where Apple was more reasonable. The only people who are even really aware of the difference TODAY are those who follow the industry. Ask anyone else, and the only thing they’ll be aware of is the lack of Flash support, if even that. That’s not what this is about, really.

Furthermore, it really irks me to hear Apple fans now pointing to market success as an indicator of any legitimate superiority. You didn’t buy that argument when the Mac OS was getting killed by Windows, so you really shouldn’t be peddling it now. It’s disingenuous.

I’ll bet Apple knows what it’s doing business-wise, just like Microsoft did in the 80s and 90s. That’s not the issue. Microsoft did incredible harm to its customers and the industry as a whole, and it looks like Apple might be doing the same thing now, with many of the same techniques. THAT’S the issue. The masses may not realize the harm. Like Microsoft with Windows, Apple has succeeded in making the iPhone “the easy choice”—the one people will buy when they don’t know what’s best.

As long as a large percentage of the market is ignorant (which will always be the case with technology), market success points to very little besides marketing success. Nobody here is questioning Apple’s marketing decisions.

I’ll grant that it’s a matter of perspective. If all I wanted was to see Apple make heaps of money, I’d be thrilled. But such loyalty would be misplaced. I’m not that much of a fanboy. My own interests, the industry’s interests, the culture’s interests and society’s interests will trump Apple’s interests in my view any day.

I’ll also grant that it’s possible Apple is making the right move, even from that perspective. But if you want to argue with me or Bosco or Mr. Rentzsch on that point, you’re on the wrong battleground.

Gregory Lawhorn

I don’t know programming environments, but I’ve used Apple stuff for 23 years. It beats the competition for user experience, hands down. I’ve never been so impressed by the competition, whether Windows or Zune or Droid, that I’ve thought that Apple was producing an inferior product or missing some huge piece of the pie.

In short, Apple’s developer rules work. Don’t like ‘em? Write programs for the Zune, and make me so jealous that I switch platforms.

Bosco (Brad Hutchings)

Gregory, the funny thing about what you write is that you admit to not know what the issue is, extol 20 years worth of development freedom, and then conclude that the rules is the rulez. In plainer English… For 20 of the 23 years that you’ve been an Apple customer, there weren’t any rules, and yet, you still loved the experience.

Nemo

Dear Bosco:  Calling my arguments a lie is an assertion, not an argument.  Since you don’t oppose my argument, it stands as unopposed. 

As for the examples of RIA that you cite, your argument is a prime example of the misleading arguments that Adobe and others will be forced to make, for none of the examples that you cite come even close to fully supporting the iPhone OS’s complete list of published APIs.  Thus, none of your examples permit a developer to fully exploit all that the iPhone OS has to offers, so that he can exploit, if he so chooses, the capabilities of the iPhone OS to the fullest, but must instead be limited to the features of the iPhone OS that the developer of the tools chooses to support.  That picking and choosing by developers of tools which of the iPhone OS’s APIs their tools will support is what Apple’s new Section 3.3.1 puts to an end.

Now, my reading fo Section 3.3.1 suggests that much of the reporting and debate about Section 3.3.1 is built on a false premise, that new Section 3.3.1 forbids developers to use third party tools to make their apps for the iPhone OS and thus, restricts developers to Apple’s tools.  While there hasn’t been any official word from Apple, I don’t believe that this is true.  As I read new Section 3.3.1 (Section),  it permits the use of third party tools to develop apps for the iPhone OS, provided that those tools are constructed with and use the open standards of HTML5, CSS, and Javascript and the non-discriminatorily licensed H.264 and fully support all of the iPhone OS’s published APIs.  And, thus, Adobe or anyone else can, by using the standards described, supra, and by fully supporting all of the the iPhone OSs APIs, make tools to develop apps for the iPhone OS.  Steve Jobs strongly hinted that this is the correct reading of Section, where, at the end of his “Thoughts On Flash,” he said “New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.”

Adobe and others’ problem with Section isn’t that they can’t make tools; it is that they can’t make proprietary tools, which, if they obtained sufficient market share, as Adbobe has now (at least 75% of video, games, and interactive content), will allow one or a few of them to be the gatekeeper(s) for multimedia content on the Internet and, thus, be able to charge a monopoly rent for their proprietary tools.  Making tools based on open-source or at least non-discriminatorily licensed standards opens the tool making business to everyone for all to compete on the merits:  Don’t like Apple’s Gianduia; then use SproutCore or something else.  But whatever you choose, it will be built on and use standards, fully support all of the iPhone OS’s published APIs, and can be translated to another set of tools without such a great burden of expensive work as to make the translation impractical.

Adobe problem isn’t that it can’t make tools for the iPhone OS under Section; its problem is that it tools would have to be based on standards that would force it to compete and deprive it of any chance of being the gatekeeper of the multimedia content on the Internet, as it now is.

Bosco (Brad Hutchings)

Nemo, you throw a lot of buzzwords out. They each come with a set of facts associated with them. Some I could spend an hour and dispute, provide all sorts of evidence why they aren’t correct.

Apparently, correctness isn’t grounds for winning a debate. Flinging 20 paragraphs of disjointed rhetoric is the new standard. That’s well and good, but if your 20 paragraphs rests on a false assertion, as I have pointed out, it’s more likely literary diarrhea than anything remotely useful.

Like I’ve said before… Told you so time will be a fun time for me. My revolution actually showed up this morning, with Walt Mossberg noting that Flash isn’t about video, it’s about dynamic, interactive content. That’s light years ahead on the truthiness scale of where you and the loyal Apple lovers are on this. But I’m sure if I tune in next week, you’ll find some way to say the same thing, deny that you ever believed anything different, and then parrot the new Apple line about dynamic content ruining battery life.

On a side note, desktop Safari started choking regularly on one of my favorite blogs. Slow scripts. It doesn’t know how to manage them. And people call Flash a CPU hog. Open a terminal, type “top”, and hit that link. Nemo, the rhetorical term that doesn’t take 20 paragraphs is “glass houses”.

John C. Welch

Funny brad, how in your world, everyone who blindly agrees with you is smart, educated, and applying real analysis to the situation, and everyone who even mildly disagrees is just blind, stupid, and sucking up to Apple.

Funny how that works out.

Also, your ignorance of Apple’s history is hilarious.

Ask a few companies like Franklin how “open” apple used to be.

I bet you think old Macs never had any problems either.

gplawhorn

Bosco, the funny thing about what YOU write is the implication that Apple’s user experience quality has been due to a lack of the “rulez” (must be developer talk). I figure that Windoze has the same lack of “rulez” that you imply Apple had for two decades, yet Windoze sukz (this is fun). Personally, I believe that Apple succeeds because The Steve has a feel for what works and what doesn’t. Apple is a money-making concern, of course, but if money was the only issue then Apple wouldn’t care any more about user experience than Microsoft.

Bosco (Brad Hutchings)

Huh? I guess you don’t know about my bet with Bryan, with whom I vehemently disagree, but who makes a reasoned case for his opinion. I point out a discrepancy of fact underlying Nemo’s lengthy argument, and he as much as says it doesn’t matter.

John, the main point of this discussion is section 3.3.1. A term like that is unprecedented in the mainstream computing industry of which Apple has been a part since the mid 70s. Even in handheld space, it’s unprecedented among popular devices. One company having control of what apps appear on its platform and what apps don’t is also unprecedented among mainstream desktop and handheld general purpose computing devices. That was my point to Gregory, who is happy with Apple’s draconian control because he’s apparently been happy with it for 23 years.

OK, I just saw gplawhorn’s reply. One thing I think we can all agree on is that nobody here has any sense of humor. Geez. I’ll try not to keep it light for fear of offending anyone’s sense of grammar.

John C. Welch

Brad, if it’s about 3.3.1, then why are you blindly defending Wolf’s complete mischaracterization about it. Let’s recap that quote:

Section 3.3.1 makes developers wholly reliant on Apple for software engineering innovation.

That’s not kind of wrong, that’s not sort of wrong, that’s completely wrong, and it’s from a source that most definitely knows better. 3.3.1 doesn’t apply to Mac devs *at all* and it doesn’t apply to anyone writing in-house applications that will never show up on the application store. It is a verifiably false statement. Yet you are defending it, because it agrees with your viewpoint. You don’t care that it’s incorrect. You only care that it agrees with you.

Agrees with Brad? Good.
Disagrees with Brad? Bad.

Correctness and accuracy are immaterial, only agreement with Brad matters.

As well, if you seriously think section 3.3.1 is “unprecedented in the mainstream computing industry”, then your knowledge of the that industry’s history is a) dreadfully incomplete and b) evidently doesn’t include a minor player called IBM.

IBM who told you point blank that you could only hook IBM components up to its computers…which you had to lease. you couldn’t buy them.

3.3.1 unprecedented? only if you’re ignorant Brad, only if you’re ignorant.

Bosco (Brad Hutchings)

John, why do you think Rentzsch is talking about the Mac when he clearly is talking about the iPhone? Have you ever heard of “applications” that span both desktop and mobile? That’s my interest.

Let me clarify my “unprecedented” statement. It’s unprecedented in the desktop personal computing device era. Is that better? Let’s eliminate big iron from IBM, Cray, and whomever else.

Technically, you’re right about enterprise apps with 100 or fewer unit deployments. In practice, that size enterprise deployment can be difficult to manage with un-jailbroken iPhones. It also narrows the market for tools.

The more I think about it though, the better that Apple goes down the Draconian road. It forces all the other big players to go on record with which side they’re on and then try to lure developers to either climb their hills or glide into their valleys. Such a shame to see a company and brand I have liked since I was 9 turn into this though.

John C. Welch

John, why do you think Rentzsch is talking about the Mac when he clearly is talking about the iPhone? Have you ever heard of ?applications? that span both desktop and mobile? That?s my interest.

Not my job to read anyone’s mind. Wolf wrote the words, he can either correct them or stand by them. Either works, but as written, it’s crap, and you know it, you just won’t admit it.

Let me clarify my ?unprecedented? statement. It?s unprecedented in the desktop personal computing device era. Is that better? Let?s eliminate big iron from IBM, Cray, and whomever else.

Nice job of moving the goalposts. But that still doesn’t make 3.3.1 unprecedented. it’s just the first time it’s ever affected you. Reality is terribly inconvenient for you, isn’t it.

The more I think about it though, the better that Apple goes down the Draconian road. It forces all the other big players to go on record with which side they?re on and then try to lure developers to either climb their hills or glide into their valleys. Such a shame to see a company and brand I have liked since I was 9 turn into this though.

You really, really have no clue about Apple’s, or anyone other computer company’s history, do you. You’re like everyone else who overpersonalized Apple and fooled themselves into thinking it was some kind of special, different company.

It wasn’t. Ever. They make great products. Buy them or do not buy them.

But stop pretending Apple made you drink that Flavor-Aid. Apple never even gave you any. You mixed it all up yourself, drank it yourself, and now that you realize what you’ve been drinking, it’s Apple’s fault.

But, given your new-ish fandom for Adobe and Google, i see a lifetime of rude awakenings for you until you stop pretending corporations are your friend.

Mikuro

Now, my reading fo Section 3.3.1 suggests that much of the reporting and debate about Section 3.3.1 is built on a false premise, that new Section 3.3.1 forbids developers to use third party tools to make their apps for the iPhone OS and thus, restricts developers to Apple?s tools.? While there hasn?t been any official word from Apple, I don?t believe that this is true.? As I read new Section 3.3.1 (Section),? it permits the use of third party tools to develop apps for the iPhone OS, provided that those tools are constructed with and use the open standards of HTML5, CSS, and Javascript and the non-discriminatorily licensed H.264 and fully support all of the iPhone OS?s published APIs.

You’re right, they don’t ban other development tools per se, but they do ban other languages. From the agreement:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

So yes, you can use development tools made by other companies…..as long as they’re just like Apple’s. Forget REALbasic. Forget anything like HyperCard. Forget Python (which seems especially strange, since Apple supports making Cocoa apps in Python with XCode 3). Forget Java. Forget anything new that comes down the road.

Any color as long it’s black.

I’ll say it before and I’ll say it again: OS X has benefitted greatly from the diverse array of tools available to developers, and this diversity has not created a lack of first-rate Mac apps that exploit all of Apple’s whiz-bang features. Actually, I find it kind of annoying how MANY apps use OS X’s latest and greatest features, because they won’t run on older versions of OS X!

I’m not a fan of Java, but there are a few Java apps I’d hate to be without. Ditto for Qt.

So, I think the risk of alternate development tools ruining the iPhone ecosystem is overblown.

Nemo

Dear Bosco:  Your problem is that I’ve rebutted your arguments and your misleading facts, and you don’t have anything else, other than assertions and name calling, and more misleading statements.  Who ever said that Flash didn’t involve more than video?  Certainly, I didn’t maintain that Flash dealt with only video.  For example, I said, supra, “if they obtained sufficient market share, as Adbobe has now (at least 75% of video, games, and interactive content),”.  You’ll note that I mentioned interactive content.  But all of this, including your misleading reference to Mr. Mossberg’s comments, is simply a deflection to cover that you can’t rebut my arguments.  So you’re left with name calling, specifically calling me a liar and a fool, and deceptive misleading statements, such as misrepresenting what Mr. Mossberg said and throwing up Real Studio and MoneyBread, when you know or should know that neither of those tools fully supports the iPhone OS’s full list of published APIs and, therefore, don’t rebut the argument that Translators limit developers to a weak subset of the iPhone OS’s capabilities.

Well, now that I’ve reduced you to name calling, deceptive misleading statements, and excuses, such as I could rebut your arguments if I wanted to take the time but I won’t deign to stoop so low or every dog has its day and my day will come, and crap like that, I am pretty sure that reasonable people will see your arguments have collapsed and are totally unpersuasive.  As for your day coming, I am sure that it will arrive, and on that day all dogs will rejoice, until then adieu.

Bosco (Brad Hutchings)

Nemo: I rebutted your argument that third party tools are unable to use platform APIs with a direct, verifiable example. Mikuro has two very good related points above, that (1) sometimes the platform whizbang stuff gets in the way of usability and (2) there are many indispensable tools built with crappy cross-platform UI kits.

And no, I did not mischaracterized Mossberg’s comments in a video interview with one of the WSJ web shows at all. He spoke frankly about interactive content his own paper continually develops to enhance story presentation on the web and he said it was questionable if HTML5 was up to the job.

Bosco (Brad Hutchings)

...and throwing up Real Studio and MoneyBread, when you know or should know that neither of those tools fully supports the iPhone OS?s full list of published APIs and, therefore, don?t rebut the argument that Translators limit developers to a weak subset of the iPhone OS?s capabilities.

I’ve actually been very generous with my time in the forums explaining this particular tool and the course that REAL Software has taken toward a loose, informal goal of supporting iPhone OS. It has been the number one requested feature by REAL’s customers. They have a feedback system where you can verify that if you’re a customer. They have outlined the steps they would need to take toward that goal in their public newsletters, and one by one, checked off those steps. They were certainly on course.

The thing I know from being an expert user of the tool is that every wrapper class in REAL’s frameworks have access to the platform-native “handle” (loosely speaking). Using that, and writing a declare, the developer has direct access to any published API in the platform SDK and the appropriate parameter to send to it. Many times, REAL will build platform-specific classes to support platform-specific features in REALbasic’s style. For example, I can slap a masked picture onto my app’s Dock icon dynamically now by assigning a REALbasic picture. It’s a fairly recent feature. To do that in the past required declares or a plugin.

You might make the point that while the facilities are available, less expert programmers might not be capable of using them. True enough, even in practice. These less expert programmers would have no chance of developing whatsoever with Apple’s tool chain. And maybe that’s really what this is about… “protecting” the precious platform from less expert programmers. Paint them as the Chinese dog food of the computing industry. Protectionism doesn’t work for nation states. And it won’t work for platforms. Econ 101. The rhetoric really gets your hearts pounding, but it’s horrible, horrible policy and will just make the platform and its users poorer.

Nemo, it’s just obvious you’re out of the pool of what you understand discussing this. I doubt I’ll change any minds here until you all begin to see the consequences of what Apple is doing. You’ll see them. No doubt.

Nemo

Bosco:  The only problem is that “third party tools are unable to use platform APIs” isn’t now and has never been my argument.  As I originally stated and restated again and again, my point is the point that Apple makes implicitly in new Section 3.3.1 (Section):  That Section permits competing third party tools, but those tools must, inter alia, fully supports the complete list of the iPhone OS’s public APIs to be permitted under Section.  That’s has been my point from the beginning.  And you cannot find any instance where I have said anything different or where I deviated deviated therefrom.  So no, you didn’t adduce any third party tools that addressed my point, that satisfied the requirements that Apple set out in Section, and that have consistently been the basis of my argument in my posts. 

Even Mikuro, who you cite for support, acknowledges that Section does not ban third party tools per se, if those tools satisfy Section’s requirements, which are simply these three things:  (1) the third party tools be written in objective C, C, or C++; (2) those tools are constructive with and use the open source tools of Javascript, CSS, and HTML5; and (3) those tools fully support the complete lists of the iPhone OS’s public APIs.  I don’t know of any third party tools that satisfy Section, except perhaps, one, which I am not at liberty to discuss, and apparently neither do you, but any third party can easily make tools that do satisfy those requirements.  So, if Adobe wants to get in the game, it can take up Steve Jobs’ invitation to get in the game by writing HTML5 tools. However, of course, that will mean Adobe must sacrifice its oligopoly.

As for Mikuro, I don’t understand his complaint.  Is he suggesting that instead of an open language, Apple require that third party tools be written in proprietary languages of its competitors, such as .Net or Adobe’s proprietary language for Flash and AIR?  Of course, tools have to written in and use some language.  Objective C is the native language of OS X and its derivatives, such as the iPhone OS.  To accomodate developers who want to write for the iPhone OS but not learn its native language, Apple accommodates them by also offering C and C++, two widely known and open languages that any competent developer must be familiar with and that are taught in every accredited computer science cirriculum.  Perhaps Mikruo can suggest another open language that he wants Apple to permit under Section.  Surely, Mikuro doesn’t maintain that Apple must permit in Section and support every language, open or not, that any developer might want.

His contention that Section forces a tool maker to write tools just like Apple’s is patent nonsens.  You can use Section’s prescribed languages and standards to write tools of capabilities and variety that are limited only by one’s imagination and ability, provided that they use the prescribed standards and languages and fully support the complete list of the iPhone OS’s public APIs.  Section places no other limits or requirements on third party tools, so a maker of tools is free to create and innovate tools that not only meets Section’s requirements but that exceed Apple’s tools, if it/he has the talent to do so.

What Walt Mossberg said:  Walt said that neither Adobe or Apple could claim that its products is open source.  He said that Flash is proprietary, and so is the iPhone OS and the iPhone OS’s SDK, which is fine for Apple, because it has never claimed to be an open source company.  Apple has only maintained that Section requires that third party tools use the prescribed open-source standards.  Walt did say that Flash is used for, among other things, interactive content.  So what?  First, that fact isn’t relevant to this dispute in that it neither proves or disproves anything in contention.  And neither I or Apple has ever said anything that contradicts what Walt said.  So, once again, so what?

Nemo

Bosco:  I opine that Real can write whatever tools that its wants for the iPhone OS, provided that it meets the three requirements of new Section 3.3.1 that I stated, supra.  However, the day of third parties providing tools for the iPhone OS in their proprietary standards is done.

Bosco (Brad Hutchings)

Time to pull out Section 3.3.1 again…

3.3.1 ? Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Nemo, it says, explicitly, that applications themselves must be coded in C, C++, or Objective-C. It also says that application may only link against documented APIs, not intermediary frameworks. Your lack of conceptual understanding of what these mean is the problem here. Let me help you grab the essential concept. I’m going to use REAL Studio and its REALbasic language as an example.

One thing you may have to do with Objective-C and Apple’s frameworks is release objects so that they don’t sit in memory once they are not used anymore—if you’ve created them so that the garbage collector can’t handle them automatically. You have to explicitly release them.

NSString* string2 = [[NSString alloc] init];
[string2 release];

If you don’t release that NSString, it just sits in memory forever. That’s called a memory leak, and if your app does it often enough, it can suck up megabytes of memory and slow down the whole machine. Apple’s API makes it easy to bypass garbage collection and create these kinds of problems.

With REALbasic, however, it is difficult to create that kindof situation. You can end up with circular references that the garbage collector can’t detect, but you can do that in Objective-C also. What you can’t do in REALbasic without a lot of deliberate work (usually involving plugins or declares) or the circular reference thing I mentioned, is allocate objects that won’t be disposed of when they are no longer used.

Expert programmers like me enjoy the higher level of abstraction that lets us focus on the application rather than these low-level intricacies over most of our code. Less expert programmers are insulated from common mistakes that the lower level language makes too easy to make.

Now, if you re-read section 3.3.1, you will notice that it explicitly disallows using a higher level language.

The other component of a development tool like REALbasic is frameworks. These are also disallowed by 3.3.1, as they are not the Documented APIs. Let’s say that for a certain class of applications that 1000 developers might write, there is a complicated sequence of calls to Documented APIs that will invariably be the same. The tools vendor wraps this complicated sequence into a single call to its wrapper API. Thus, 1 developer has to get it right, and 1000 developers benefit and never even have the opportunity to get it wrong. That is what 3.3.1 disallows.

Let me put it this way Nemo… It’s like if there were a private arbitration board that parties to a contract could agree to use to settle disputes. But the private arbitration board will only accept contracts that are hand written from memory, left handed, with a quill pen on hand-made paper. You would know intellectually that those requirements would necessarily increase the costs and lower the quality of contracts by prohibiting the cost saving and quality increasing technologies (e.g. word processors, contract databases, laser printers) that your craft has adopted. This is exactly what Apple is trying to do to my craft.

Faboys may love it because it sticks to it arch-enemy and all-around bad guy Adobe, but it sticks it worse to every other developer who cares about his customers and picks the best tools to meet their needs in the most cost-effective way possible. Because of Apple’s current dominance in mobile apps, it also ends up casting incorrect and inappropriate aspersions beyond Apple’s market reach in software development. Look at the bile tossed in these forums toward cross-platform apps that span Mac/Windows. It’s like if you refused to use that hypothetical arbitration service and customers told you that you were an idiot for having Word or Pages in your workflow.

Does this finally make sense to you?

Mikuro

Surely, Mikuro doesn?t maintain that Apple must permit in Section and support every language, open or not, that any developer might want.

I do indeed. Why on earth should I not be allowed to choose whatever tool I deem to be right for the job, the same way I can with Mac development?

Perhaps I’m reading you wrong, but it seems to me like you think that any development tool is fair game as long as it is written in accord to Section 3.3.1. If that were the case it would essentially be a non-issue. The issue is that any tool that lets you write apps in a language besides Objective-C, C, C++ and JavaScript cannot be used to make apps for distribution. Again, from Section 3.3.1: “Applications must be originally written in Objective-C, C, C++, or JavaScript” This is what I mean when I say “just like Apple’s” (yes, it’s hyperbole; it doesn’t need to be EXACTLY like Apple’s, but still close enough to be incredibly limiting, owing to the language restriction).

The idea that OS X has a ‘native language’ doesn’t seem quite right. Objective-C is the de facto standard, but a language is just a language, and is really not so closely tied to Cocoa and OS X. Cocoa is what really makes OS X apps “native”, and Cocoa is a framework, not a language. There’s no reason you couldn’t write native Cocoa apps with Python. In fact, you can on Macs. But it’s a big no-no on the iPhone now. Why? Can anyone make a reasonable argument against Python? I’d love to hear it.

That Section permits competing third party tools, but those tools must, inter alia, fully supports the complete list of the iPhone OS?s public APIs to be permitted under Section.  That?s has been my point from the beginning.

You’ve said this a few times now, but I see nothing in the agreement that says either A) that apps made with tools that support all APIs will be allowed or B) that apps made with tools that do not are not allowed. Can you elaborate? As I read it, the restrictions they make are based on languages used. If I make a shitty tool that lets you write apps in Objective-C but doesn’t let you access all of Apple’s APIs, it seems that would be A-OK, actually. If I write an awesome tool that lets do you do everything with all of Apple’s APIs, but using, say, SmallTalk, that would not be okay.

And we haven’t even talked about the implications of the phrase “any private APIs”, which Section 3.3.1 expressly forbids. Does that include any Objective-C framework, even if it’s based on nothing more than Cocoa? Does this mean reusable classes are outlawed?!? WTF? Clearly this is not Apple’s intent, but it’s still in the agreement. “API” is a fairly broad term, and few apps can be written without something that could be described as a private API. Does this mean I can’t use something like AGRegex for iPhone apps? Again, WTF?! I can only assume Apple is using an unusually narrow definition of “API”, but this needs to be clarified by Apple. I haven’t talked about this before because I really don’t understand it.

Bosco (Brad Hutchings)

@Mikuro: The “private APIs” in the old 3.3.1 referred explicitly to private Apple APIs, and were widely understood to refer to them. So if Apple had an undocumented API for controlling the camera or the GPS receiver, you couldn’t use that in your app. Here’s the text of the previous 3.3.1:

3.3.1 ? Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

For the non-programmers… The private, undocumented APIs are easily discovered with simple, common reverse engineering techniques. Once discovered, they are often shared in non-Apple-official forums. Discover once, use many.

Nemo

Mikruo:  Your position is ridiculous.  Have you any idea of the expense and technical complexity of supporting every language that any developer might wish to use.  No one does that.  Adobe and Microsoft certain don’t do that.  You get their respective proprietary languages and are lucky if you get any open language.  No one support every language because that is practically impossible.  So a maker of an OS or of tools picks one or at best two or three languages.  Apple in providing three languages provides much more than most.

And Bosco, once again, so what?  Objective C, C, and C++ are the languages that OS X has supported since its earliest alpha releases over a decade ago.  It, therefore, is not surprising that Apple’s choose those languages as the ones for iPhone OS’s third party tools.  Now Real may have some nice features that you prefer to Apple’s tools.  If you hope to have those features available to you, you should encourage Real to issue tools with those features in Section’s prescribed languages and standards with full support for the complete list of iPhone OS’s public APIs.  Otherwise, until others release third party tools that comply with Section’s requirements, you will be using Apple’s tools, just as I must use English as the official language in courts of record in the U.S., with other languages only being permitted to provide due process when dealing with a party that isn’t fluent in English, except for the U.S. District Court for Puerto Rico, where proceeding are conducted and records kept in Spanish.  Also, the Federal Rules of Court describe in excruciating detail exactly how documents have to presented to the court, describing the formatting down the smallest detail.  Failure of counsel to comply with those requirements can result in the filed document being stricken from the record and the case proceeding, as if they hadn’t been filed, or in counsel being sanctioned.  If you were familiar with rules that govern the major arbitration organizations, you would know that they have similar rules of procedure for presenting documents to the arbitrator(s).  The courts do, however, give greater latitude to pro se parties, but the courts will only let pro se parties go so far in deviating from the Rules.

Bosco (Brad Hutchings)

Again Nemo, you talk past the isssue. You say “rules exist”. You refuse to address evidence presented by Mukuro and me in this thread that the “rules are inappropriate and even counter to their oft stated intended purpose”. Your line about REAL being allowed to deliver something if it follows the rules demonstrates either a lack of understanding about languages and frameworks or a passive aggressive dickishness that really doesn’t belong in a civil discussion. I’m going to give you the benefit of doubt and assume the former. However, when it comes to Apple and Steve Jobs, it’s more than obvious it’s the latter.

Nemo

Bosco:  I don’t know what purpose you’re referring to.  Section is perfectly consistent with the purposes that Steve Jobs stated in his “Thoughts On Flash.”  To wit: tools for the iPhone OS must comply with the requirement of Section, because those tools are best suited to the modern age of mobile touchscreen devices and to making an ecosystem of better apps for the iPhone OS.  Section’s requirements are appropriate to and consistent with these purposes. 

I decline and don’t need your benefit of the doubt.  Real has to comply with Section, if it wants to make tools for development on the iPhone OS.  In this, Apple and I are being no more dicky that Adobe or Microsoft or Real, whose requirements for using their tools or frameworks are at least as severe and restrictive as Apple’s developers’ agreement for its SDK.  And in Adobe’s case, it is more restrictive:  You use its language and you use its tools as it says that you can.  And if you fail to do so, Adobe will sue the crap out of you.  HTML5, Javascript, and CSS are far less restrictive, because they are open.  However, because they are open, you can’t build a oligopoly or monopoly using them but must compete on the merits.  If that is being a dick, then I am a dick.

Mikuro

Have you any idea of the expense and technical complexity of supporting every language that any developer might wish to use.? No one does that.? Adobe and Microsoft certain don?t do that.? You get their respective proprietary languages and are lucky if you get any open language.? No one support every language because that is practically impossible.? So a maker of an OS or of tools picks one or at best two or three languages.? Apple in providing three languages provides much more than most.

Please re-read my last post, specifically the paragraph beginning “perhaps I’m reading you wrong”. I would really like you to elaborate on that, because I feel a disconnect here. One of us must be operating under a false assumption. I explained what I think is your false assumption above. Please explain if you think I’ve misinterpreted you or Section 3.3.1. It seems to me that you misunderstand the meaning of Section 3.3.1. But hey, I could be wrong. I’m honestly asking for clarification.

I’m not sure what you mean by “supporting every language” here. Certainly Microsoft and others don’t actively support every language in existence. That is, they will not provide tools to write apps with BrainF*** (yep, that’s a real language) or help you if you have problems with BrainF***. But Microsoft and even Apple (as far as Mac development goes) will not stop you from using BrainF*** if you desire, or any other language anyone comes up with. They won’t stop you from distributing programs written in BrainF***. They really don’t care what you use to write programs. Apple IS preventing that for iPhone developers. That’s the difference. You can’t tell me this is the way it’s always been. That’s plainly false. (And I’m not sure why you mention Adobe in the same breath, since they don’t do anything equivalent to an OS.)

Again, I feel a disconnect here.

Bosco (Brad Hutchings)

Nemo: There are basically two interpretations of the “purpose” of 3.3.1. One is to cock block Adobe’s CS5. The other one, which you have repeatedly alluded to very directly, is to ensure high quality software. I can point out examples until I’m blue in the face where Objective-C makes certain classes of mistakes easier to make, more difficult to track down, and more costly in problems to end-users than higher level languages like ActionScript and REALbasic. You also contend that higher level languages can’t access the platform native APIs. I make a direct refutation for the one that I know best, and you continue to assert that it’s impossible for a high level language to do that.

So far as development tool SLAs go… Here is the full developer license for REAL Studio. The only two things it does is try to ensure that developers purchase the appropriate number of developer seat licenses and disclaim warranties. OK, so it also has a restriction of reverse engineering. Doesn’t everything that isn’t explicitly open source since 1985? There are no runtime fees or license restrictions, etc. This SLA is a paragon of reasonableness and low friction for a commercial product. It sure as hell doesn’t say, for example, like the Snow Leopard end user SLA, that generated text to speech can’t be broadcast or publicly “displayed” (wrong word, but you know what I mean).

Nemo, this is what frustrates me about you. You make a contention about something, I give you an example where your contention is so untrue, it ought to be borderline criminal, and then you’ll say it’s immaterial. It is material, because 3.3.1 goes against the real day to day standards and norms of this industry that aren’t written down anywhere, but everyone in the practice pretty much knows what they are and goes along with them so we can focus on our customers and not be at each others’ throats.

Isn’t there something similar in the courtroom that you just don’t do? Maybe a bombshell blonde 35 year old prosecutor going with a skirt that’s like 1/2 inch shorter than anyone else might do? Hey, as a juror I voted to convict a DUI suspect probably because of just that. (Kidding, well, probably.) Mikuro senses a disconnect. I’m really trying to find a connection on your turf that you can relate to.

Log-in to comment