Fraser Speirs Cocoa and Photos

Bampot of the Week: Alexander Wolfe

John Gruber has his occasional Jackass Of The Week award, for which Rob Enderle seems to be in line for a lifetime achievement award. I needed a more Scottish equivalent, so here is my Bampot¹ of the week: Information Week’s Alexander Wolfe, for his overblown and incorrect piece about the iPhone SDK entitled “iPhone SDK Developers Angry At Apple’s Tight Control”.

Let’s take the piece apart, Gruber-style:

Apple’s mindset is apparent from the get-go. They’ve gone non-disclosure crazy with the iPhone SDK, though admittedly no more nuts than usual. Here, what they’re doing is keeping the all the stuff people want to know under much tighter wraps than they need to. For example, you can download the iPhone SDK for free, but you have to pony up $99 to get at the really good documentation, sample code, and developers’ videos.

This is simply not correct. Firstly, the NDA is a standard thing for pre-release software from Apple and many other companies. The iPhone NDA is little different to others I’ve seen but to discuss the contents of the NDA any further would be to break its terms.

Wolfe makes a factual error in stating that you have to pay $99 to get the documentation and sample code: you get that when you download the SDK. The documentation, samples and videos are available for the price of registering for a free ADC Online developer account. The videos are available via Apple’s ADC on iTunes service.

OK, that’s relatively minor. Pay the $99 and be done with it. I think the bigger problem for developers is going to be death by a thousand cuts. By this, I mean that Apple never seems to put all its cards on the table at once. For example, on Sunday Phonemag reported that the SDK contains a tidbit noting that the iPhone won’t run more than one app at a time, so when users switch applications, whatever is running in the background will get killed.

If Apple “never seems to put all its cards on the table at once”, how come we know about the no-background-threads limitation? If it were a hidden limitation, we would only learn about it when someone tried to write a background app and it failed to work. Documenting limitations isn’t the same thing as hiding them.

From Apple’s standpoint, this is done to maintain decent performance. However, developers are likely to see it as just another screwing.

If Apple had promised me that I would be able to write supported background applications with the SDK then, yes, I would feel screwed. However, to my knowledge, no such promise was made. Having used Windows Mobile devices that do allow process to live on in the background, I can only hope that Apple enforces this limitation as rigidly as possible. Nothing else makes sense for the user in a resource-constrained environment like a phone.

The trick for we developers is to make it look like the app was running all along.

Me, I want to know what’s supposed to happen if you’re in the middle of something important and your iPhone rings. Does your app blow up?

Yes, the only possible explanation for what happens when another app is launched is that the iPhone deliberately crashes the one you’re working in. For “blow up”, let’s substitute “get suspended, saving its data for later resumption” and then we can answer yes.

The same thing will happen to your app when the user hits the Home button. Does Wolfe think that the Home button will be made into a “crash my app” button in iPhone 2.0?

There’s lots of complaining about the fact that all iPhone apps have to be approved by Apple, will be sold by Apple, and Apple will get a 30 percent cut of all sales. On the other hand, John Siracusa at Ars Technica says that “developers see dollar signs” in iPhone apps, so presumably they’ll deal with the restrictions.

Great argumentation: “lots” of unlinked, unattributed ‘complaints’ and the one attributed remark actually refutes the point of the paragraph.

Turns out, though, that developers are limited in what iPhone functions that can tap for the apps they’re building, according to Adam Houghton’s post on his eponymous blog. Houghton characterizes as a “glaring” omission his discovery that developers can’t access calendar appointments, music and videos from the phone’s iPod app, nor phone and SMS functionality.

So there’s missing functionality. The SDK is beta. File an enhancement request.

How is Apple’s rule that only apps it has signed can run on the iPhone going to play when it comes to corporate applications? One commenter on Slashdot …

…and that’s the point at which you have to laugh and close the tab.

This is a lot to digest, and quite frankly most developers will suck it all up because, hey, it’s the iPhone.

I think, right now, “most” developers serious about the iPhone are still reading and reading and writing test apps and figuring things out. Despite it being a lot to digest, that’s apparently no reason for Wolfe to hold off on filing an ill-informed attack piece on an SDK he clearly has not even downloaded and investigated. If he had done so, Wolfe would know that you don’t have to pay $99 to get the documentation, sample code or videos.

Wolfe seems to have totally missed the point about the SDK. He mostly seeks to criticise the no-background limitation, but the majority of unresolved questions in all of this are about the App Store. Here are my questions:

• How do we do a public beta release without charging for it? I never charge users for beta releases.
• Will developers be able to generate coupon codes for free downloads? This is very important for promotional purposes.
• How will the App Store handle discounted upgrades to new versions? Upgrades keep the lights on in year 3.
• How and under what circumstances might Apple revoke an application’s right to run? Does the customer get a refund, and from whom?
• How will it handle demo versions? Trying before buying is important. Seems like this would be easy to do with FairPlay embedded in the applications.

For me, those are the real questions. The technology is great (which, given the NDA, is about as much as any developer should be saying about it right now) and all the known unknowns are about the business deal.

[Update: 1. Bampot (Scotland, slang, pejorative) idiot; an objectionable and foolish person.]

That’s a remarkable amount of bampottery in one article. Enderle must surely be proud.

What I’m not sure is: are these people really really stupid, or do they just focus on the fact that controversy gets readers? I’m not convinced either way, in truth.

I don’t think the “don’t talk about the terms of the contract” clause would actually hold. After all, you have to be able to read it to decide if you’ll sign it, and until you sign it, you’re not bound by its terms. So, anyone could read the licenses, summarize them, and *only then* actually sign and be bound by it for the future.

Of course, I’m not a lawyer…

I’ll go with Jackass. I’m not sure what a Bampot is. He should have done his research before writing the article. Did he take the time to download the SDK and read the docs or did the 2Gb download scare him off.

@Uli: My only thought was that the access to the SDK agreement might itself be covered by a more general ADC-wide NDA agreement, which would protect it.

A worthy glaswegian variant on the Gruber approach! I think we’re all trying to process lots of new components here. It makes a lot of the Leopard technologies introduced mysteriously at WWDC fit more comprehensibly when you factor in Cocoa touch development.

What really makes my head hurt is how the success and growth of the WebKit project is really a key part of the puzzle…if they didn’t have such a robust browsing experience, a lot of the phone/touch apps would seem…well, like desk accessories. And so we have a huge open source project at the core…wrapped in closely-held frameworks and signed/gatekept by a company determined to keep malware off their device.

I’m spending today rediscovering Dashcode…suddenly a lot more interesting to me when you can run a fullscreen web app with local data storage and SVG and native-fast queryselectors on the simulator. And in some strange way, I’m having HyperCard flashbacks.

Yes, I’m that old.

“something is happening here and you don’t know what it is… do you, Mr Wolfe…”

This piece from Alexander Wolfe was the last straw for me. I’ve added Information Week to my “do not click under any circumstances” list, and I sent an email to IW to tell them why. The response I received is pretty classic. They’re basically proud of this kind of sensationalistic hit piece because it draws clicks. Here is their response:

—

David,

Sorry to hear you feel this way, and yes we do care–in fact we care a lot.

Alex actually runs one of the fastest growing Blogs inside InformationWeek, and
yes it grows fast based on the juicy headlines, creating some contention and the
other things that make a Blog good. Make no mistake, it is an InformationWeek
Blog, even though Alex has built a brand around his own name. However, you are
right, we definitely take more liberty in blogging than we do in a major feature
or a news story–there is a difference between these things in our approach.

Everyone on this e-mail does not want to lose you as a user of our site, nor do
we consider it ‘click whoring’ to write content that gets people riled up–that
is the beauty of blogging and that is the beauty of people like you who care
enough to send this sort of note.

I hope you reconsider and click on that link, or revisit “Wolfe’s Den” to see
what else Alex is up to. But if you do not, then I respect the hell out of you
for caring enough to send this note and I wish you well.

John

John Siefert
Vice President, Publisher
InformationWeek l TechWeb Network
TechWeb, The Global Leader in Business Technology Media
O: (949) 223-3642 | E: JSiefert@techweb.com
A Division of United Business Media LLC

Hey, why the shot at Rob Enderle? Enderle has a great track-record of predictions. Whatever he predicts seems to nearly always have an precisely inverted relationship with reality.

I don’t agree with your assessment of background applications, mainly because I was going to write an app which relies on being able to run in the background (a kind of ad-hoc social network thing). No background apps means no Skype, no MSN or Adium, no third-party mail application and a ton of other apps we won’t see on the iPhone.

A understand that Apple doesn’t want to be associated applications that use undocumented APIs, with porn, or with things like Skype. Fair enough. But at least give us a way to distribute such applications outside Apple’s App Store, please.

Wolfe makes a factual error in stating that you have to pay $99 to get the documentation and sample code: you get that when you download the SDK.

But you have to become a Registered iPhone Developer to get the SDK. As far as I can tell, in order to become a Registered iPhone Developer (that is, join the iPhone Developer Program), I’d need to pay either $99 or $299. If that isn’t the case, how do I get the iPhone SDK from Apple without paying any money?

The alternate explanation is that the iPhone Developer Program and being a Registered iPhone Developer are completely separate: that one can become a Registered iPhone Developer, and thereby get the SDK, without joining the iPhone Developer Program. Apple’s website does not make this clear at all; it does say that the SDK is “free”, but also makes no distinction between registering and joining the Program, which implies (to be, and apparently to Wolfe) that they are the same, which would mean that you need to join the Program to get the SDK.

LKM said: ‘But at least give us a way to distribute such applications outside Apple’s App Store, please.’

No problem…it’s called YOUR WEB SITE. Apple is only going to be the gatekeeper for the applications that it sells directly from their web site. Don’t like their restrictions, fine!, don’t sell your apps on their web site.

@LKM: Such a way exists, albeit unofficially. The iPhone Dev Team reports that the beta firmware 2.0 has been cracked and made to allow unsigned applications, among other things. Certainly, the hackish nature of something like this will make about 3/4 (this is not a random number, but based on discrepancies between Apple’s numbers and those of the carriers that have iPhone exclusivity) of current iPhone owners unlikely to try it, but it is done.

Still, for Apple to support both ways would not make sense. As far as I would like them to, they’ve settled on the controlled distribution medium for now. It’s up to consumers to show Apple they are not pleased with this.

@Peter: You don’t need anything but a free ADC account to download the SDK. In order to be allowed to test your apps on your phone (via cable) or to sell them, you must pay the $99.

@Peter:
You can register and download right away without paying any money. In fact, you *can’t* pay Apple any money right now. They don’t seem to have started accepting paid developer program memberships.

@Dru:
Apple made it quite clear that you won’t have the option to distribute your apps elsewhere. There is some sort of enterprise development option for non-public apps, but that is not intended for public sales of apps.

@Peter:

There’s a big fat “download the SDK” button on the iphone developer page. You do need to log in to your ADC account, but that’s free to create. I think you can also log in with your iTMS account, also free.

To become a “registered developer”, which afaict only means that you’ll be allowed to submit apps for sale via Apple, does cost $99. Some people will find that cost prohibitive (teenagers, students, etc) — I remember being 16 and wishing that Apple would sell the Inside Mac books for printing cost instead of $29.95 (in retrospect, low-volume, large-format, 300-page books in 1986 probably did cost about that much to print, distribute, etc). In this case, the $99 is probably designed to put some control on the workload of the iPhone app staff.

Apple announced that they’ve had 100k downloads of the SDK so in the first four days. It’s 2.1GB, so that’s 210TB of data transfer. (And if they were charging for the download, $10MM of revenue!

@Dru:

There’s no evidence that I’m aware of that you’ll be able to distribute iPhone apps thru any channel other than the Apple iPhone app store. There’s some debate over the likelihood that registered developers will be able to run apps distributed directly by other registered developers. But remember, in the absence of a “dev” mode or something similar, all apps on the iPhone will have to be cryptographically signed by Apple. That means the App Store.

I’m not convinced this is a bad thing. Apple’s 30% take is probably fair. Checking out the other “share/freeware” aggregator sites (for PDAs/phones and desktops too!) reveals a poor user experience.

Remember this is a mainstream huge-market consumer device. And remember that “software sells systems”. Apple wants to make sure that no one misses an opportunity to be aware of all the cool apps available for the platform. This benefits everyone, tho I agree that the details Fraser listed will be important to get right. It’s early yet, but I’m only encouraged so far.

It will be interesting to see how the status of Web Apps plays out. I wonder if they will be presented in the iTunes store for free - much like Podcasts in audio.

Assuming (!) networked applications (Google apps etc.) are going to get ever more competent, is there a point at which native apps become obsolete?

@Jonathan:

Never.

Until network latency is zero, native apps will provide a better experience. That said, a ubiquitous, always-on platform will lead to a point where any app that doesn’t sync to the net and make its data available through other interfaces _will_ be obsolete. This is why the iPhone SDK matters so much — like the iPod, others have tread down the path before, awkwardly, blindly, incompetently…but Apple has delivered what the others couldn’t. Call it speculation, but I’d bet a business on it.

@David Dugan: I hate to say it, but I think the reply you posted from InformationWeek was polite, reasoned, honest, and respectable. I don’t get the disdain. I may not agree exactly with the tactics, but it is hard to argue that the message itself is “pretty classic.” “Unexpectedly refreshing” is more like it.

Apparently not all purveyors of trash are also stupid…

Geoff

@Geoff… I agree that Information Week’s response was polite and honest. In fact, the problem that I have is with the honesty… that they feel Alexander Wolfe’s tactics are completely in line with their publication… that using a Slashdot commenter as the foundation for a “good blog entry” is fine, because it “creates some contention” and makes for “juicy headlines”. I don’t buy into the idea that an established publication like Information Week can publish crap and simply justify it by labeling it as a blog entry.

I’ve been reading Information Week forever, and I was getting issues of MacWeek mailed to me in 1993, and if Wolfe’s kind of sensationalist click-whoring is what they want to be about, then I’m no longer interested in giving them the satisfaction of my clicks. This has been a long time coming, but this latest hit piece from Wolfe was the straw that broke my back.

How else are we ever going to get some integrity back to some of these major online publications, other than voting with our mouse clicks (or iPhone taps)?

There is indeed a lot of interest in writing apps for the iPhone, _despite_ the restrictions and the publishing model where Apple will profit from other peoples work. That doesn’t make it right.

If MS did this first, imagine what you’d say. For me, I hope that Apple will face an antitrust trial as soon as possible.

Microsoft *did* do this first. Ever hear of XBox Live Arcade? No, the XBox isn’t a phone, but the models are pretty much identical: A locked-down device where all third-party applications pass through approval by the manufacturer.

Except that it looks like Microsoft is a far stricter gatekeeper than Apple will be; it isn’t easy at all to get a game approved for XBLA.

@Andrew…it’s not clear that the code has to be cryptographically signed by Apple. I read it as Apple issuing each developer a public-key certificate signed by the Apple certification authority (I suspect that’s what the $99 buys). A developer would sign his own code with the associated private key. The signed code would contain the certificate. The OS would verify the code’s integrity and signature and verify that the associated certificate had been issued by Apple and had not been revoked.

To me this means that Apple would not be in the business of evaluating and approving applications (except maybe those with more privileges, for example if AOL’s IM program requires background services). Instead, it will be able to determine what programmer has been naughty (or maybe incompetent) and either get the program fixed (the automatic notification of upgrade would be handy here) or take away the keys to the kingdom, i.e. revoke the certificate.

It may be that Apple will only allow installation through its facility but the need to “approve” the code should not be the reason why.

@Dru Richman: You’re wrong. I can’t sell an iPhone app on my web site because users won’t be able to install it.

@inaequitas: Telling my users to hack their iPhone to install my app (thereby potentially voiding the warranty, and preventing them from installing Apple’s updates if they want to keep using my app) is not an option.

You write: “Still, for Apple to support both ways would not make sense.”

Why not? I’d argue it’s the *only* way that makes sense. The way things are now, I can’t even give a copy to my friends, or send out review copies, or do a beta test - which is what I’m mainly concerned with. I don’t even *want* to sell my app outside the story. I’m happy with the 30% Apple gets. I’d even be happy if they got 50%. All I want is to be able to give my friends, my beta testers and reviewers copies they can put on their phones.

I’m surprised you even dignified that original article with a reponse? Clearly it was written by someone who does not know, for people who do not know. There are people out there who only want to hear what they know, and only learn what they suspect. For those, this article is further confirmation that Apple is losing market share, has draconian DRM policies, forces everyone to buy iPods and that the iPhone is nothing but a fancy toy for the overpaid.

Now excuse me, while I go off to read up on Objective C, and get started on my first iPhone app…

Great piece, Fraser

Fraser,

in answer to your questions:

* How do we do a public beta release without charging for it? I never charge users for beta releases.

* How will it handle demo versions? Trying before buying is important. Seems like this would be easy to do with FairPlay embedded in the applications.

Shouldn’t these two be covered by the option to offer an app for free?

You could upload the beta as a free offer, then pull it off the store once your app goes final and put a price tag on it. A demo could be realised by offering the demo version as a free app, and the full verison with a price tag.
Or am I missing something?

How will the App Store handle discounted upgrades to new versions? Upgrades keep the lights on in year 3.

Maybe this is an inappropriate desktop analogy? From what I can see in the iPhone SDK philosophies, iPhone apps are meant to be small and stay small, so emerging a growing code base over three years might make less sense than just writing many different small apps over that time. Also, if we’re looking at price points under $5, as Jens Alfke suggests, pricing the upgrade cycle starts to fall apart: how do I price an upgrade to a $2 app? Maybe the answer is that you don’t: you write another $2 app instead.

Oh, so InformationWeek isn’t worried about the accuracy of the article because it was posted in a blog, not printed, even though the blog is owned by them. They also seem to indicate that they aren’t going to worry about accuracy because it is a popular blog.
Accuracy be damned so long as it sells, I guess.

@LKM

If you want to give away your app free or just give a beta app away there is nothing stopping you from doing so. Apple specifically said that they would host free apps on the store and not charge a fee.

Background workaround?

Given what launchd can do in terms of on-demand launching, is it not possible that traffic on certain ports might give rise to launch of an app pop-up like the one you get when an SMS comes in while you’re using the Calculator or the Weather app?

I’m not claiming this is a 100% solution, but launchd offers some fairly impressive on-demand launch capabilities. Are these not available on iPhone as on other MacOS X?

And, yes: “news” outlets don’t make their revenue based on the amount of truth in their stories, they make the revenue as a result of things like banner ad impressions, paid clicks on ad links, and so on. Truth is difficult to ascertain, challenging to convey, and otherwise problematic to handle. Just spewing stuff that sounds alarming enough to get a few eyeballs is pretty simple, and that’s where “news” has got to in the US. I’m not sure it’s better elsewhere, of course, but they aren’t news outlets, they’re ad outlets.

Bampottery indeed. Not only did I learn a new synonym for “jackass” but that Information Week considers blogs free of that pesky “truth” thing, whatever that is.

@Hoyt:

You’re right, the who-signs-apps-and-when part is still somewhat unclear — but I’d expect it to work something like SSL certificates work today, and I’d expect the certificates to be per-app rather than per-developer.

We’ll find out soon enough, but my guess is that Apple will sign last, as a final step before making the app available on the Store. I don’t have any guesses w/r/t their acceptance criteria, other than the stated HIG and security stuff.

@Hoyt also:

Note that if Apple is making itself the certificate authority (likely), then signing the apps will cost them nothing. A second or two of CPU time each. It’s only if you need a certificate chain that goes all the way back to one of the big blessed authorities that you have to pay for the privilege. Apple can and should bless itself.

@Uli: I’m not a lawyer either, but it looks like it’s a two step process. You first have to agree to “Registered iPhone Developer Terms and Conditions “. This is public and states that all information you receive as a Register iPhone Developer will be confidential. Then, afterwards you get to see the “iPhone SDK Agreement”, which is the one we’re not allowed to disclose the terms of. Very clever.

Great article except for this:

“Having used Windows Mobile devices that do allow process to live on in the background, I can only hope that Apple enforces this limitation as rigidly as possible. Nothing else makes sense for the user in a resource-constrained environment like a phone.”

That is pretty weak. Overall the SDK is great. But the lack of backgrounding is a huge deal for a lot of apps. And my blackberry doesn’t seem to have too much of a problem with a background app or two. Perhaps it would just be better to let the user decide, at least a bit, if they are willing to take a performance hit, to, say, have a multiprotocol IM client running in the background? Or get alerts from a dedicated facebook/twitter app? Or have updated news stories for my RSS reader ready to go when I launch the app?

In fact, from my perspective, those three apps are the ones I would most want for the iPhone that I now really won’t be able to have without a lot of creative programming, e.g. Multiprotocol IM will have to be done through a third-party server that stores messages and will cost money (Verichat).

Frasier:

Nice piece, and I agree with you on most points - this was a hack piece.

I’ve got to disagree with you on one piece, and agree with aktsuki: I have several ideas for iPhone apps I’d like to write that cannot be accomplished with the SDK as it stands now. The blanket ban on background processing is unreasonable. There has to be a way that apps can have code fire in the background (the way mail and calendar do to check for new mail or appointments). It doesn’t have to be an unrestricted ability to run in the background, but some mechanisms for running code and/or firing notifications at certain times or under certain conditions would be extremely helpful. Maybe it’s in there somewhere, but so far I haven’t found it, and I’ve been working my way pretty steadily through the SDK documentation since last Thursday

As far as I can tell you can do everything you want through the announced App Store mechanism. Your Beta is simply a free app that has an upgrade (automatically offerred when available) that costs money. If you want to offer coupons, just have a variant of the app available at a lower price that requires the user enter a coupon code the first time it runs. They’ve already described the auto upgrade mechanism, which presumably let’s you charge what you want for upgrades, distinct from the program cost. Etc.

here here to hypercard.

You could sell source code for your apps and ask your customers to compile it themselves (paying an additional $99). This way Apple can not prevent your apps if it does not like them. Problem is that one would have no way of prevent the customers to further share the source code.

But for free apps or donation-ware this might work. Except that by downloading the SDK one might agree not to give away any source code. Unfortunately, nobody having read the SDK would be allowed to answer that question for me. But maybe we could discuss formulations Apple might use in their legal agreements, so everybody can download the SDK find the answer on her or his own.

Oh look an angry nerd blogwar this will surely affect something somewhere.

@LKM (but not only) The way I’m understanding it so far, apps that devs want to give out for free will be free only for devs. I got it from one of the Apple blogs (TUAW I think) that all apps will cost something, be it as little as $0.99.

I don’t think it makes sense for Apple to do both because the goals of those two models are somewhat contradicting. Don’t get me wrong, I want the same as you. But if Apple decided to go the App Store route, to also offer a free way would subvert their goal of making money. Because maybe devs will want to get the entire payout and go around the App Store. That may be in the interest of a Free Market, I know, but after all, Apple’s calling the shots for now. Just as there was no SDK a while back and they ‘gave in’ so maybe they will give into alternative distribution media.

As Fraser posted, though, I am curious on how betas and try-before-you-buy will work — though I do have some ideas, involving time trials before the App Store forces you to buy or remove the app.

I followed the link from DF, good piece. One question though, can we get a pronunciation on “Bampot”? It’s not a word I run across often.

@kdt: You’re proposing releasing beta-quality apps in the Apple store. Not going to happen.

@Kyle: Actually, a kind of hypercard-clone was another project I’ve shelved, since iPhone apps won’t be allowed to execute code.

@inaequitas: Free apps are permitted, but useless for my problem. And no, the two models are not contradicting. Pay Apple 99 bucks and be on the App store (which 90+% devs would do anyway), or don’t pay and don’t be on the store. I don’t see the contradiction.

Again, almost nobody has a problem with pay Apple 30%. I’d gladly pay more to be on the store. The problem is that it’s simply not practical to do stuff like beta tests or send out review copies with this model. This isn’t a contradiction, it’s simply a missing piece.

Am I the only one that remembers writting software on the Palm? It wasn’t until version 4 or so when you could finally have a background process. This was several YEARS later.

Your app was suposed to run, until the user changed their mind, then “resume” when they decided to use your app again.

It worked for Palm

“Yes, I’m that old.”

Bah!

Real old-timers want to know how we’re going to read Hollerith cards with the iPhone.

-jcr

“Again, almost nobody has a problem with pay Apple 30%. ”

Only people who’ve obviously never made a distribution deal with any other software publishing firm.

-jcr

>Your app was suposed to run, until the user changed their
>mind, then “resume” when they decided to use your app
>again.

Otherwise known as “behave like a game, not like a useful application”