Monday
10Mar2008
Bampot of the Week: Alexander Wolfe
Monday, March 10, 2008 at 07:35AM
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 Bampot1 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:
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.
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.
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.
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?
Great argumentation: "lots" of unlinked, unattributed 'complaints' and the one attributed remark actually refutes the point of the paragraph.
So there's missing functionality. The SDK is beta. File an enhancement request.
...and that's the point at which you have to laugh and close the tab.
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:
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.]
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.]
Reader Comments (12)
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" :-P
���! ���������� ������� �������!
Excellent!
__
ParaSlim