I always figured the lack of SDK was because the iPhone is a quick poorly planned rush to market and Apple cut an exclusive demonic deal with ATT to run on their outdated network. The iPhone is basically an expensive trinket designed for maximum profitability rather than as an innovative tool.
Apple has gotten about as far from its hacker roots of building blue boxes as possibly imaginable. Otherwise, the iPhone would be totally hackable running Java, Python, Brew and whatever and definitely not locked into Ma Bell. Instead it would be wifi / voip oriented designed to be revolutionary not iCandy with restrictive use and memory.
To go back to your wikicache example, if the phone had adequate memory and was enabled to use WiFi / WiMax for bulk downloads or even a data oriented cellular platform like 3G the phone network wouldn't even notice. ATT's archaic network and restrictive user agreement is the problem, not the app. I am sure you could exceed the user agreement limits just by sending a lot of photos or video on a regular basis. The kind of stuff you are supposed to be able to do with a smartphone. Their 'unlimited internet' is pretty limited. The ATT network just isn't designed to handle a lot of bits, it's designed to charge people for voice calls by the minutes.
Basically it's like trying to drive a modern car on a cowpath. So what the iPhone is essentially is a cow cart designed to look sorta like a Ferrari. Cow sold separately, by Ma Bell exclusively.
Daniel Miessler
· 2 years ago
You make an excellent argument -- one very similar to that of a close friend. What I think you're missing, however, is that Apple isn't *trying* to build a "hacker box" of any sort. They're trying to do a very few things really well. Here's my argument:
The iPhone is such a new device for Apple that they've had to control development of the device. The original iPod never had third party devices hook into it. These didn't come until the 3rd Gen iPods.
Web2.0 and AJAX are very powerful development environments as can be seen by Google Docs among others and as more people are developing AJAX than Cocoa it is a major coupe for development enabling more people to develop SAFE apps for it.
Oh and just a pendantic side thought it's "faux paux" not "feux paux". :-)
Zhasper
· 2 years ago
Nope. It's not "feux paux", and it's not "faux paux" either, it's "faux pas".
You americans have funny ideas about french..
But back to the point...
What makes Apple's situation different to Nokia or Sony-Ericsson's situation with their Symbian phones, or anyone with a Windows based phone? They all provide SDKs that allow applications such as "WikiCache" to be built - why is it not a problem for them?
You seem to be hinting that there's something different in Apple's case, something that makes them unable to do what Nokia/SE/O2/iJam have been doing for years, but you don't explain what....
Daniel Miessler
· 2 years ago
LOL
I've corrected my faux pas faux pas. :)
But I'm not American. I'm a Chinese-African. Let's see to it that you don't make that mistake again.
Daniel Miessler
· 2 years ago
> What makes Apple’s situation different to Nokia or Sony-Ericsson’s situation with their Symbian phones, or anyone with a Windows based phone? They all provide SDKs that allow applications such as “WikiCache” to be built - why is it not a problem for them?
Because they aren't attracting tons of developers to write applications for them as a popular, interesting thing. Hence the people that *do* write them tend to be more experienced.
This is different with the iPhone SDK because Apple would advertise it all over the place, and thousands of casual quasi-programmers would find the notion of using it VERY attractive. And of course the tool would be very easy to use. Want to make a network call? Drag and drop! Etc.
In short, the iPhone SDK would be different because it would attract thousands upon thousands of people who should not be programming at all, and then it would be easy enough that they could actually create something dangerous without getting discouraged. The other tools weed people out either by not advertising themselves or by requiring more programming knowledge to even get started.
Zhasper
· 2 years ago
Because they aren’t attracting tons of developers to write applications for them as a popular, interesting thing. Hence the people that *do* write them tend to be more experienced.
This is different with the iPhone SDK because Apple would advertise it all over the place, and thousands of casual quasi-programmers would find the notion of using it VERY attractive. And of course the tool would be very easy to use. Want to make a network call? Drag and drop! Etc.
Sorry, I thought we were arguing based on reality, not based on the featureset of some mythical SDK you dreamed up.
I'm going to counter your Apple-makes-an-SDK-that's-really-simple-for-noobs fantasy with an Apple-makes-an-SDK-no-simpler-for-noobs-than-existing-SDKs-for-similar-phones fantasy. Something like an extra API or two exposed in xcode, plus a cross-compiler and some libraries that one has to pay Apple money for, coupled with a contract on which the developer agrees not to create anything that will cause problems on the network.
But getting back to reality-based discourse... Have you *seen* the quality of some of the apps for S60/UIQ/Palm out there? There are, very definitely, a lot of inexperienced programmers already creating apps for existing phones, principally with J2ME. So, your argument that the iPhone's mystical SDK would be the first to attract inexperienced programmers is irrelevant.
Secondly, I think Dave Winer has a much more reasonable suggestion about why there's no SDK - no SDK == no Skype == no competition for AT&T, with whom Apple had to work closely in order to be able to get the features they want on the phone.
Daniel Miessler
· 2 years ago
On your first point, I agree that there's a huge number of Palm app programmers that don't know what they're doing, but I think the hype around the iPhone will generate an even more novice dev crowd. First of all Apple already has a ton of developers that would be likely to start programming immediately if an SDK were released -- not to mention the fact that the AT&T; will take ALL the traffic from poor iPhone apps built with an SDK. There wouldn't be any distribution of the pain; it would all fall on them.
I also think that the stability of the device is also a major consideration. Palm has succeeded because they are an application platform. It's a basic computer that you can run all this crap on, and if you like to run tons of crap at the expense of stability, then that's your device. But Apple (I think) wants to sell an appliance. Extensible to some degree, but never sacrificing the stability of the phone or iPod. They want it to remain in a known-good configuration, and I think they're banking that this will prove more valuable than the immediate release of the SDK.
As for the Skype argument, I haven't read his thoughts on the matter but it does seem odd to me that Apple would sacrifice ALL development capability simply to stop a single application. I see what you're saying about the genre of VOIP in general, but it seems to me like AT&T; would stop that at the network level rather than killing the whole SDK to stop it on the local side.
Thoughts?
Zhasper
· 2 years ago
First point: I need to steal your blockquote style at some point, it's very pretty
Second: you say that "AT&T will take ALL the traffic from poor iPhone apps built with an SDK" like it's a bad thing. Here in .au, all of the providers charge quite nice (for them) rates for data - mostly on the order of 5c/kb. One provider instead charges 20c per minute, in 5-minute blocks. In other words, most of our providers would *love* to have the traffic generated from poorly-written apps - in fact, they're quite experienced and writing watertight contracts so that they can benefit from poorly-written apps on the existing phones.
Judging from your comment though, it sounds like this isn't the case where you are. Do AT&T have some kind of all-you-can-eat data plan or something like that, that would end up costing them money if someone used a lot of data?
To some extent I agree that the remain-in-known-good-configuration is quite likely. One of Apple's biggest strengths has always been the lack of choice in their product offerings: eg, when choosing a macbook, you can choose the amount of ram, the size/speed of hard drive, but that's about it - the only real choice of hardware you get is that you can sometimes choose between two different video cards, or lately, two different types of monitor. This makes their product offering very simple to support: there's a very limited range of hardware -> very few drivers -> easier to ensure that the drivers work reliably. Contrast with Windows, which supports a huge range of hardware -> huge range of drivers -> huge numbers of people with varying skill level writing drivers -> less stability.
Also, the most recent product aside form the iPhone was the iTv - no SDK for that either, no support for third-party apps (that I know of - everything that's been added has been hacked on, right?)
So, it would fit with their model to provide limited choice and extensibility, aiming to have something that works consistently. I do agree with that.
As for it being odd that Apple would make an agreement with AT&T that led to them not offering an SDK simply to stop VOIP apps - I don't think that's any more peculiar then them only selling the phone through one particular network. Well - from an Australian perspective at least, that's very odd - maybe it's more common to have a phone model tied to a particular provider over there?
It's just occured to me though that there's at least one VOIP provider who could still happily have an interface on the iPhone, despite the lack of an SDK: JahJah (http://www.jajah.com/)! They could turn this into a great opportunity - they're the only provider I can think of who provide that functionality, so they're uniquely placed to be the only VOIP provider who can have an interface on the iPhone..
Zhasper
· 2 years ago
So, I blogged about my comment. Also, it annoys me that you don't respond to my trolling. At the same time, the fact that you give meaningful responses makes me respect you more...
Daniel Miessler
· 2 years ago
Also, it annoys me that you don’t respond to my trolling. At the same time, the fact that you give meaningful responses makes me respect you more…
1. It was unfortunate that they only brought the iPhone to a single carrier, and it is unorthodox here i the U.S. as well. I think that goes back to Apple controlling variables.
2. I think they're more worried about losing customers based on the charges that their poorly written apps cause. If they have an unlimited plan then AT&T; eats it, if not then the customer gets this massive bill. They may pay it but they will be unhappy from that point on. They're trying to limit the ways in which customers can have negative experiences. Again, I agree that it's a *consumer* device, not a super-hacker device.
3. iTV is different because it's an entertainment device rather than an important life appliance. If you bork your iTV because you messed it up with 3rd party crap, you just can't watch movies for a while. If you do the same with your phone you might need Apple or AT&T;'s help -- and it will be a major hassle for both the consumer and the providers.
4. I think it's very strange to stop an entire SDK just to stop a single application (Skype). Even if they were doing it to stop ANY VOIP applications, I think it'd be much easier to do that from the network side while still allowing the SDK to go forward and bring more customers in. The fact that they didn't do this is, in my opinion, because they were worried about the impact to their network and device stability by doing so. Especially right at launch. I think it's very possible that they may release it later, after they've seen what impact the iPhone is going to have, and have learned to defend the network better.
5. Interesting idea about JahJah. I'll look out for a web-app from them.
6. Your first comment sounded a bit hostile -- which seemed uncharacteristic of you -- but I figured you were just having a bad day. But your comments I didn't take as trolling; it seems like legitimate discussion to me. No worries, man. I know you're cool. :)
All Comments
I always figured the lack of SDK was because the iPhone is a quick poorly planned rush to market and Apple cut an exclusive demonic deal with ATT to run on their outdated network. The iPhone is basically an expensive trinket designed for maximum profitability rather than as an innovative tool.
Apple has gotten about as far from its hacker roots of building blue boxes as possibly imaginable. Otherwise, the iPhone would be totally hackable running Java, Python, Brew and whatever and definitely not locked into Ma Bell. Instead it would be wifi / voip oriented designed to be revolutionary not iCandy with restrictive use and memory.
To go back to your wikicache example, if the phone had adequate memory and was enabled to use WiFi / WiMax for bulk downloads or even a data oriented cellular platform like 3G the phone network wouldn't even notice. ATT's archaic network and restrictive user agreement is the problem, not the app. I am sure you could exceed the user agreement limits just by sending a lot of photos or video on a regular basis. The kind of stuff you are supposed to be able to do with a smartphone. Their 'unlimited internet' is pretty limited. The ATT network just isn't designed to handle a lot of bits, it's designed to charge people for voice calls by the minutes.
Basically it's like trying to drive a modern car on a cowpath. So what the iPhone is essentially is a cow cart designed to look sorta like a Ferrari. Cow sold separately, by Ma Bell exclusively.
http://dmiessler.com/archives/1385
Let me know what you think.
The iPhone is such a new device for Apple that they've had to control development of the device. The original iPod never had third party devices hook into it. These didn't come until the 3rd Gen iPods.
Web2.0 and AJAX are very powerful development environments as can be seen by Google Docs among others and as more people are developing AJAX than Cocoa it is a major coupe for development enabling more people to develop SAFE apps for it.
Oh and just a pendantic side thought it's "faux paux" not "feux paux". :-)
You americans have funny ideas about french..
But back to the point...
What makes Apple's situation different to Nokia or Sony-Ericsson's situation with their Symbian phones, or anyone with a Windows based phone? They all provide SDKs that allow applications such as "WikiCache" to be built - why is it not a problem for them?
You seem to be hinting that there's something different in Apple's case, something that makes them unable to do what Nokia/SE/O2/iJam have been doing for years, but you don't explain what....
LOL
I've corrected my faux pas faux pas. :)
But I'm not American. I'm a Chinese-African. Let's see to it that you don't make that mistake again.Because they aren't attracting tons of developers to write applications for them as a popular, interesting thing. Hence the people that *do* write them tend to be more experienced.
This is different with the iPhone SDK because Apple would advertise it all over the place, and thousands of casual quasi-programmers would find the notion of using it VERY attractive. And of course the tool would be very easy to use. Want to make a network call? Drag and drop! Etc.
In short, the iPhone SDK would be different because it would attract thousands upon thousands of people who should not be programming at all, and then it would be easy enough that they could actually create something dangerous without getting discouraged. The other tools weed people out either by not advertising themselves or by requiring more programming knowledge to even get started.
Sorry, I thought we were arguing based on reality, not based on the featureset of some mythical SDK you dreamed up.
I'm going to counter your Apple-makes-an-SDK-that's-really-simple-for-noobs fantasy with an Apple-makes-an-SDK-no-simpler-for-noobs-than-existing-SDKs-for-similar-phones fantasy. Something like an extra API or two exposed in xcode, plus a cross-compiler and some libraries that one has to pay Apple money for, coupled with a contract on which the developer agrees not to create anything that will cause problems on the network.
But getting back to reality-based discourse... Have you *seen* the quality of some of the apps for S60/UIQ/Palm out there? There are, very definitely, a lot of inexperienced programmers already creating apps for existing phones, principally with J2ME. So, your argument that the iPhone's mystical SDK would be the first to attract inexperienced programmers is irrelevant.
Secondly, I think Dave Winer has a much more reasonable suggestion about why there's no SDK - no SDK == no Skype == no competition for AT&T, with whom Apple had to work closely in order to be able to get the features they want on the phone.
On your first point, I agree that there's a huge number of Palm app programmers that don't know what they're doing, but I think the hype around the iPhone will generate an even more novice dev crowd. First of all Apple already has a ton of developers that would be likely to start programming immediately if an SDK were released -- not to mention the fact that the AT&T; will take ALL the traffic from poor iPhone apps built with an SDK. There wouldn't be any distribution of the pain; it would all fall on them.
I also think that the stability of the device is also a major consideration. Palm has succeeded because they are an application platform. It's a basic computer that you can run all this crap on, and if you like to run tons of crap at the expense of stability, then that's your device. But Apple (I think) wants to sell an appliance. Extensible to some degree, but never sacrificing the stability of the phone or iPod. They want it to remain in a known-good configuration, and I think they're banking that this will prove more valuable than the immediate release of the SDK.
As for the Skype argument, I haven't read his thoughts on the matter but it does seem odd to me that Apple would sacrifice ALL development capability simply to stop a single application. I see what you're saying about the genre of VOIP in general, but it seems to me like AT&T; would stop that at the network level rather than killing the whole SDK to stop it on the local side.
Thoughts?
Second: you say that "AT&T will take ALL the traffic from poor iPhone apps built with an SDK" like it's a bad thing. Here in .au, all of the providers charge quite nice (for them) rates for data - mostly on the order of 5c/kb. One provider instead charges 20c per minute, in 5-minute blocks. In other words, most of our providers would *love* to have the traffic generated from poorly-written apps - in fact, they're quite experienced and writing watertight contracts so that they can benefit from poorly-written apps on the existing phones.
Judging from your comment though, it sounds like this isn't the case where you are. Do AT&T have some kind of all-you-can-eat data plan or something like that, that would end up costing them money if someone used a lot of data?
To some extent I agree that the remain-in-known-good-configuration is quite likely. One of Apple's biggest strengths has always been the lack of choice in their product offerings: eg, when choosing a macbook, you can choose the amount of ram, the size/speed of hard drive, but that's about it - the only real choice of hardware you get is that you can sometimes choose between two different video cards, or lately, two different types of monitor. This makes their product offering very simple to support: there's a very limited range of hardware -> very few drivers -> easier to ensure that the drivers work reliably. Contrast with Windows, which supports a huge range of hardware -> huge range of drivers -> huge numbers of people with varying skill level writing drivers -> less stability.
Also, the most recent product aside form the iPhone was the iTv - no SDK for that either, no support for third-party apps (that I know of - everything that's been added has been hacked on, right?)
So, it would fit with their model to provide limited choice and extensibility, aiming to have something that works consistently. I do agree with that.
As for it being odd that Apple would make an agreement with AT&T that led to them not offering an SDK simply to stop VOIP apps - I don't think that's any more peculiar then them only selling the phone through one particular network. Well - from an Australian perspective at least, that's very odd - maybe it's more common to have a phone model tied to a particular provider over there?
It's just occured to me though that there's at least one VOIP provider who could still happily have an interface on the iPhone, despite the lack of an SDK: JahJah (http://www.jajah.com/)! They could turn this into a great opportunity - they're the only provider I can think of who provide that functionality, so they're uniquely placed to be the only VOIP provider who can have an interface on the iPhone..
1. It was unfortunate that they only brought the iPhone to a single carrier, and it is unorthodox here i the U.S. as well. I think that goes back to Apple controlling variables.
2. I think they're more worried about losing customers based on the charges that their poorly written apps cause. If they have an unlimited plan then AT&T; eats it, if not then the customer gets this massive bill. They may pay it but they will be unhappy from that point on. They're trying to limit the ways in which customers can have negative experiences. Again, I agree that it's a *consumer* device, not a super-hacker device.
3. iTV is different because it's an entertainment device rather than an important life appliance. If you bork your iTV because you messed it up with 3rd party crap, you just can't watch movies for a while. If you do the same with your phone you might need Apple or AT&T;'s help -- and it will be a major hassle for both the consumer and the providers.
4. I think it's very strange to stop an entire SDK just to stop a single application (Skype). Even if they were doing it to stop ANY VOIP applications, I think it'd be much easier to do that from the network side while still allowing the SDK to go forward and bring more customers in. The fact that they didn't do this is, in my opinion, because they were worried about the impact to their network and device stability by doing so. Especially right at launch. I think it's very possible that they may release it later, after they've seen what impact the iPhone is going to have, and have learned to defend the network better.
5. Interesting idea about JahJah. I'll look out for a web-app from them.
6. Your first comment sounded a bit hostile -- which seemed uncharacteristic of you -- but I figured you were just having a bad day. But your comments I didn't take as trolling; it seems like legitimate discussion to me. No worries, man. I know you're cool. :)