It obviously wasn't. I presumed you meant ALL as that would have made the sentence make sense. SOME makes your whole argument nonsensical. Yeah, the iPhone sells more than SOME other phones. No shit Sherlock....
I don't know what it is you do within your bubble, but to those of out in the real world, we recall the reams of articles written about Apple, pre-iPhone launch, going on at length about how the iPhone would be a different market from the music market, and that Apple would have an uphill fight on its hands. Some writers (whose last names weren't Enderle or Dvorak) predicted Apple had bitten off far more than it could chew.
As has been stated previously, the Apple goal at launch was 1% of the almost 1B cellphone market, or 10M in sales. By contrast, LG--which had years of experience in cell phone manufacture and distribution partners globally already in place with cellular providers--took 18 months to sell 10M Chocolate phones, which were launched in the US with an ad campaign from Verizon which rivaled the iPhone ads for ubiquity. The same total and timeframe for Apple was indeed ambitious.
The point, thus, is that not only has Apple not stumbled badly, but that it has thrived in a highly mature and competitive marketplace. It is hardly insignificant that Apple has sold more phones with a single model (and while capturing distribution relationships on the fly) than some (I'll add that word so you don't get woozy from confusion) competitors did with years of experience to assist them. Gartner placed Apple among its Top 10 sales for worldwide vendors of cell phones for 2007, and Apple was in the game for 6 months of the year.
You are correct that total global domination doesn't seem to be the company's goal, though I don't think that statement has been made in this thread. I doubt Jobs wants to be the next Samsung. What Apple does seem to want is to build an object of desire (or a few) which can provide fat margins to the company. If that was a simple goal, the Motorola wouldn't be seeking to dump its cell phone business as it makes 5 or 6 of the top 10-selling models in the US and loses hundreds of millions of dollars in the process.
Is the SDK crystal-clear and one-size-fits-all? Of course not, and it stands to reason that Apple will need to make some adjustments between now and June 30 launch, and developers will have to accommodate Apple in other areas of disagreement. Not everyone will be completely pleased and some will consider themselves disenfranchised. Life is kind of like that. But with 100,000 downloads thus far, if 50% of those downloading find the deal attractive enough and have the creativity to work within the limitations of the iPhone's structure, there will be plenty of apps available to iPhone and touch users in Q3. A few developers may take advantage of the KPCB money and build their own business, but many perhaps will be working as they do now: Part time, and as a labor of love and expression of creativity.
None of the above is terribly complicated. Perhaps some oxygen in your bubble would be helpful.
BTW, I read Speirs much earlier this morning. Any truth to the rumor that you also post under the pseudonym of Alexander Wolfe?
My point stands. It wasn't that difficult for Apple (a huge brand) to surpass SOME teeny weeny brands with poor products. I think you're way overstating your case.
No, it's not just me that has concerns over the way Apple is operating the developer program and App Store for the iPhone.
Developers don't want to be limited. That's a news flash. I think Apple will likely be somewhat flexible in some of the rules come June. But they certainly won't allow most of Rogue Ameba's requests. The iPhone is not really a general purpose computer people will not accept frequent crashes, reboots, and kernal panics. Above all its sensible for Apple to protect its stability.
Developers don't want to be limited. That's a news flash. I think Apple will likely be somewhat flexible in some of the rules come June. But they certainly won't allow most of Rogue Ameba's requests. The iPhone is not really a general purpose computer people will not accept frequent crashes, reboots, and kernal panics. Above all its sensible for Apple to protect its stability.
I very rarely get crashes, reboots and kernal panics on my SE P910. Maybe once every 4 months. It has an entirely open development process, no signing, no closed store.
OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
Indeed. If third-party software is running outside the kernel* (i.e. it is not, in whole or in part, a kernel extension) and it manages to cause a kernel panic, it's a rubbish kernel.
* this is the correct spelling. Apparently, "kernal" is the name of an operating system for 8 bit Commodores.
Apparently, "kernal" is the name of an operating system for 8 bit Commodores.
From Wikipedia:
"The KERNAL was known as kernel inside of Commodore since the PET days, but in 1980 Robert Russell misspelled the word in his notebooks forming the word kernal. When Commodore technical writers Neil Harris and Andy Finkel collected Russell's notes and used them as the basis for the VIC-20 programmer's manual, the misspelling followed them along and stuck.
According to early Commodore 'myth' and reported by writer/programmer Jim Butterfield among others, the word KERNAL is an acronym (or maybe more likely, a backronym) standing for Keyboard Entry Read, Network, And Link, which in fact makes good sense considering its role. Berkeley Softworks later used it when naming the core routines of its GUI OS for 8-bit home computers: the GEOS KERNAL.
The (completely different) OS core in the 16/32-bit Commodore Amiga series was called the Amiga ROM Kernel, using the correct spelling of kernel."
I very rarely get crashes, reboots and kernal panics on my SE P910. Maybe once every 4 months. It has an entirely open development process, no signing, no closed store. OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
Just because you don't use them certainly does not disprove the existence of software that would be detrimental to the performance on your phone.
I was just using those as broad examples. The point is that Apple wants iPhone users to have no concern any software downloaded will be detrimental to its stability or performance.
Just because you don't use them certainly does not disprove the existence of software that would be detrimental to the performance on your phone.
I was just using those as broad examples. The point is that Apple wants iPhone users to have no concern any software downloaded will be detrimental to its stability or performance.
Ermm, on my P910 I've TomTom Mobile, QuickOffice, 8-9 games, MAME, ScummVM, Agile Messenger, Gizmo5, Ogg Player and a bunch of other applications that run just fine on my phone in the background, without interfering with the phone functions, and that continue running rather than die after 20 seconds if you get a call during their use.
Some of them would be tricky to do given Apple's restrictions that you can't run background apps, can't access the dock and have no bluetooth access.
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
How do you write an instant messaging app that doesn't shut down during a phone call?
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
How do you write an instant messaging app that doesn't shut down during a phone call?
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Agreed. Just when you think Apple "gets it" (the impression given by the SDK introduction), it turns out they're still being ridiculously control-freaky with ludicrous restrictions and missing features. The bluetooth thing is just bizarre; am I right in thinking that the only thing you (as an end-user rather than developer) can do with it at the moment is use a bluetooth headset for phone calls? No file transfer, no synching, etc. etc.?
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Apps running in the background are going to have some impact on battery life as they will use memory and keep the processor working. The argument can be made for what is too much impact and what is enough. I've seen other developers report that their are ways to have apps running in the background while limiting their impact on the phones resources.
Its easier to begin with strict guidelines and ease them back, than to go the other way.
As for the missing Bluetooth profiles. Apple may have a plan for them at some point.
Its easier to begin with strict guidelines and ease them back, than to go the other way.
.
Hasn't this been Apple's M.O. since the inception of the iPhone? They pushed the Web 2.0 and it wasn't good enough. Now they'll see how far they can go with this SDK until it becomes clear it's not enough.
I initially thought that background processes would end up bogging down the iPhone, but if we're really dealing with a Mach kernel it should be able to handle multiple threads and I'm sure they could make the phone threads and email threads top priority.
Also is the system RAM shared with the Flash memory? Wouldn't it be easy to just allocate more of the memory for system functions?
"Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”
"What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."
Apps running in the background are going to have some impact on battery life as they will use memory and keep the processor working. The argument can be made for what is too much impact and what is enough. I've seen other developers report that their are ways to have apps running in the background while limiting their impact on the phones resources.
Yep, not every process is going to be CPU intensive or memory intensive, but shouldn't it be up to the USER as to what battery life they find acceptable. If they want constant updates in the background at the expense of battery, that's really up to them.
The example I gave was TomTom. It's very CPU intensive, which is why when I'm in the car, the phone is plugged in to the power socket. TomTom on the iPhone would be a killer app with the iPhone's screen.
Quote:
Originally Posted by TenoBell
Its easier to begin with strict guidelines and ease them back, than to go the other way.
As for the missing Bluetooth profiles. Apple may have a plan for them at some point.
When though? There's so much missing in the SDK that rules out a lot of applications that people take for granted on other smartphones.
"Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone?s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was ?don?t use auto-refresh.?
"What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There?s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."
I've no sympathy with someone who wants to abuse technology like that then whinge about it.
There's this technology called SMS that delivers small text messages to your phone. Perhaps he should be using that instead of pulling text down off the net expensively every 5 minutes. There's a reason push technology is desirable.
I've no sympathy with someone who wants to abuse technology like that then whinge about it.
Wanting background apps does not always equate to wanting background network access. And when it does mean that, it often is not for long, i.e. not a periodic check.
If I write a VoIP client, it would be desirable to allow the user to switch to their calendar to check a date. That requires my VoIP client to run in the background. But it wouldn't be an issue, as the connection would only last as long as the call. That should be allowed.
I see the point about keeping a connection alive hitting the battery. As a user, it's unlikely therefore I would run an app continuously that did that. Sadly, that means no incoming IM on the phone.
Anyhow, the point is, there are different levels of usage for background apps. Just because one usage pattern is really power hungry, does not mean that they should all be banned.
My solution: give apps an hour or so to run the GUI app in the background, if the app requests it. After that hour, or if resources become low, kill it. Allow small daemon tasks to stay running longer. If the daemons want continuous network access, make sure there's an easy way to turn them off and that the user is informed of the consequences. (Since Apple is reviewing all the apps, they should be able to enforce that.)
According to the AIM iPhone developers, even they don't get to run it as a background task. What they have to do is shut the app down saving the state, then when the user goes back to AIM, it restarts, gets the old state and retrieves IM messages sent whilst the user was using the other app on the iPhone. How long it does that, I don't know but presumably AOL buffer messages whilst a user doesn't have their client running. That's not a bad work around but I can see how that won't work for every app.
I suppose with my TomTom example, they could save the app state too but all this app state saving and restoring seems like pain in the arse for developers unless Apple are providing persistent app storage automatically or with minimal fuss.
That's the rub. In all probability, the user won't understand and instead just think "why does my phone have such crappy battery life?"
I can see the complaints filling Apple support lines, forums, and AI now...........
The logical extension of that would be that users should be banned from doing anything on their phone that would run the battery down, say like playing music, videos, surfing the web....
The logical extension of that would be that users should be banned from doing anything on their phone that would run the battery down, say like playing music, videos, surfing the web....
The logic is that people will think they aren't in an application - so it won't affect the battery life - and then get pissed when it does.
Maybe that's true; maybe it's not. Clearly though, that's the general logic Apple is going with, and I don't think that it's without merit.
Comments
It obviously wasn't. I presumed you meant ALL as that would have made the sentence make sense. SOME makes your whole argument nonsensical. Yeah, the iPhone sells more than SOME other phones. No shit Sherlock....
I don't know what it is you do within your bubble, but to those of out in the real world, we recall the reams of articles written about Apple, pre-iPhone launch, going on at length about how the iPhone would be a different market from the music market, and that Apple would have an uphill fight on its hands. Some writers (whose last names weren't Enderle or Dvorak) predicted Apple had bitten off far more than it could chew.
As has been stated previously, the Apple goal at launch was 1% of the almost 1B cellphone market, or 10M in sales. By contrast, LG--which had years of experience in cell phone manufacture and distribution partners globally already in place with cellular providers--took 18 months to sell 10M Chocolate phones, which were launched in the US with an ad campaign from Verizon which rivaled the iPhone ads for ubiquity. The same total and timeframe for Apple was indeed ambitious.
The point, thus, is that not only has Apple not stumbled badly, but that it has thrived in a highly mature and competitive marketplace. It is hardly insignificant that Apple has sold more phones with a single model (and while capturing distribution relationships on the fly) than some (I'll add that word so you don't get woozy from confusion) competitors did with years of experience to assist them. Gartner placed Apple among its Top 10 sales for worldwide vendors of cell phones for 2007, and Apple was in the game for 6 months of the year.
You are correct that total global domination doesn't seem to be the company's goal, though I don't think that statement has been made in this thread. I doubt Jobs wants to be the next Samsung. What Apple does seem to want is to build an object of desire (or a few) which can provide fat margins to the company. If that was a simple goal, the Motorola wouldn't be seeking to dump its cell phone business as it makes 5 or 6 of the top 10-selling models in the US and loses hundreds of millions of dollars in the process.
Is the SDK crystal-clear and one-size-fits-all? Of course not, and it stands to reason that Apple will need to make some adjustments between now and June 30 launch, and developers will have to accommodate Apple in other areas of disagreement. Not everyone will be completely pleased and some will consider themselves disenfranchised. Life is kind of like that. But with 100,000 downloads thus far, if 50% of those downloading find the deal attractive enough and have the creativity to work within the limitations of the iPhone's structure, there will be plenty of apps available to iPhone and touch users in Q3. A few developers may take advantage of the KPCB money and build their own business, but many perhaps will be working as they do now: Part time, and as a labor of love and expression of creativity.
None of the above is terribly complicated. Perhaps some oxygen in your bubble would be helpful.
BTW, I read Speirs much earlier this morning. Any truth to the rumor that you also post under the pseudonym of Alexander Wolfe?
My point stands. It wasn't that difficult for Apple (a huge brand) to surpass SOME teeny weeny brands with poor products. I think you're way overstating your case.
No, it's not just me that has concerns over the way Apple is operating the developer program and App Store for the iPhone.
Developers don't want to be limited. That's a news flash. I think Apple will likely be somewhat flexible in some of the rules come June. But they certainly won't allow most of Rogue Ameba's requests. The iPhone is not really a general purpose computer people will not accept frequent crashes, reboots, and kernal panics. Above all its sensible for Apple to protect its stability.
Developers don't want to be limited. That's a news flash. I think Apple will likely be somewhat flexible in some of the rules come June. But they certainly won't allow most of Rogue Ameba's requests. The iPhone is not really a general purpose computer people will not accept frequent crashes, reboots, and kernal panics. Above all its sensible for Apple to protect its stability.
I very rarely get crashes, reboots and kernal panics on my SE P910. Maybe once every 4 months. It has an entirely open development process, no signing, no closed store.
OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
Indeed. If third-party software is running outside the kernel* (i.e. it is not, in whole or in part, a kernel extension) and it manages to cause a kernel panic, it's a rubbish kernel.
* this is the correct spelling. Apparently, "kernal" is the name of an operating system for 8 bit Commodores.
Apparently, "kernal" is the name of an operating system for 8 bit Commodores.
From Wikipedia:
"The KERNAL was known as kernel inside of Commodore since the PET days, but in 1980 Robert Russell misspelled the word in his notebooks forming the word kernal. When Commodore technical writers Neil Harris and Andy Finkel collected Russell's notes and used them as the basis for the VIC-20 programmer's manual, the misspelling followed them along and stuck.
According to early Commodore 'myth' and reported by writer/programmer Jim Butterfield among others, the word KERNAL is an acronym (or maybe more likely, a backronym) standing for Keyboard Entry Read, Network, And Link, which in fact makes good sense considering its role. Berkeley Softworks later used it when naming the core routines of its GUI OS for 8-bit home computers: the GEOS KERNAL.
The (completely different) OS core in the 16/32-bit Commodore Amiga series was called the Amiga ROM Kernel, using the correct spelling of kernel."
I very rarely get crashes, reboots and kernal panics on my SE P910. Maybe once every 4 months. It has an entirely open development process, no signing, no closed store. OSX's kernal is leagues ahead of Symbian. I'm surprised you have so little faith in Apple's ability to produce something stable.
Just because you don't use them certainly does not disprove the existence of software that would be detrimental to the performance on your phone.
I was just using those as broad examples. The point is that Apple wants iPhone users to have no concern any software downloaded will be detrimental to its stability or performance.
Just because you don't use them certainly does not disprove the existence of software that would be detrimental to the performance on your phone.
I was just using those as broad examples. The point is that Apple wants iPhone users to have no concern any software downloaded will be detrimental to its stability or performance.
Ermm, on my P910 I've TomTom Mobile, QuickOffice, 8-9 games, MAME, ScummVM, Agile Messenger, Gizmo5, Ogg Player and a bunch of other applications that run just fine on my phone in the background, without interfering with the phone functions, and that continue running rather than die after 20 seconds if you get a call during their use.
Some of them would be tricky to do given Apple's restrictions that you can't run background apps, can't access the dock and have no bluetooth access.
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
How do you write an instant messaging app that doesn't shut down during a phone call?
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
How do you write an instant messaging app that doesn't shut down during a phone call?
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Agreed. Just when you think Apple "gets it" (the impression given by the SDK introduction), it turns out they're still being ridiculously control-freaky with ludicrous restrictions and missing features. The bluetooth thing is just bizarre; am I right in thinking that the only thing you (as an end-user rather than developer) can do with it at the moment is use a bluetooth headset for phone calls? No file transfer, no synching, etc. etc.?
Apple's restrictions are frankly bizarre and severely limit the apps you can run. How for instance could you navigate with TomTom, receive a call and go back to TomTom to discuss your route with the person on the phone if your app gets killed? That's leaving aside the need for the missing Bluetooth profiles.
Hopefully these restrictions get lifted during the beta because otherwise some applications are going to be impossible.
Apps running in the background are going to have some impact on battery life as they will use memory and keep the processor working. The argument can be made for what is too much impact and what is enough. I've seen other developers report that their are ways to have apps running in the background while limiting their impact on the phones resources.
Its easier to begin with strict guidelines and ease them back, than to go the other way.
As for the missing Bluetooth profiles. Apple may have a plan for them at some point.
Its easier to begin with strict guidelines and ease them back, than to go the other way.
.
Hasn't this been Apple's M.O. since the inception of the iPhone? They pushed the Web 2.0 and it wasn't good enough. Now they'll see how far they can go with this SDK until it becomes clear it's not enough.
I initially thought that background processes would end up bogging down the iPhone, but if we're really dealing with a Mach kernel it should be able to handle multiple threads and I'm sure they could make the phone threads and email threads top priority.
Also is the system RAM shared with the Flash memory? Wouldn't it be easy to just allocate more of the memory for system functions?
"What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."
furbo.org
Apps running in the background are going to have some impact on battery life as they will use memory and keep the processor working. The argument can be made for what is too much impact and what is enough. I've seen other developers report that their are ways to have apps running in the background while limiting their impact on the phones resources.
Yep, not every process is going to be CPU intensive or memory intensive, but shouldn't it be up to the USER as to what battery life they find acceptable. If they want constant updates in the background at the expense of battery, that's really up to them.
The example I gave was TomTom. It's very CPU intensive, which is why when I'm in the car, the phone is plugged in to the power socket. TomTom on the iPhone would be a killer app with the iPhone's screen.
Its easier to begin with strict guidelines and ease them back, than to go the other way.
As for the missing Bluetooth profiles. Apple may have a plan for them at some point.
When though? There's so much missing in the SDK that rules out a lot of applications that people take for granted on other smartphones.
"Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone?s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was ?don?t use auto-refresh.?
"What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There?s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."
furbo.org
I've no sympathy with someone who wants to abuse technology like that then whinge about it.
There's this technology called SMS that delivers small text messages to your phone. Perhaps he should be using that instead of pulling text down off the net expensively every 5 minutes. There's a reason push technology is desirable.
I've no sympathy with someone who wants to abuse technology like that then whinge about it.
Wanting background apps does not always equate to wanting background network access. And when it does mean that, it often is not for long, i.e. not a periodic check.
If I write a VoIP client, it would be desirable to allow the user to switch to their calendar to check a date. That requires my VoIP client to run in the background. But it wouldn't be an issue, as the connection would only last as long as the call. That should be allowed.
I see the point about keeping a connection alive hitting the battery. As a user, it's unlikely therefore I would run an app continuously that did that. Sadly, that means no incoming IM on the phone.
Anyhow, the point is, there are different levels of usage for background apps. Just because one usage pattern is really power hungry, does not mean that they should all be banned.
My solution: give apps an hour or so to run the GUI app in the background, if the app requests it. After that hour, or if resources become low, kill it. Allow small daemon tasks to stay running longer. If the daemons want continuous network access, make sure there's an easy way to turn them off and that the user is informed of the consequences. (Since Apple is reviewing all the apps, they should be able to enforce that.)
I suppose with my TomTom example, they could save the app state too but all this app state saving and restoring seems like pain in the arse for developers unless Apple are providing persistent app storage automatically or with minimal fuss.
shouldn't it be up to the USER as to what battery life they find acceptable.
That's the rub. In all probability, the user won't understand and instead just think "why does my phone have such crappy battery life?"
I can see the complaints filling Apple support lines, forums, and AI now...........
That's the rub. In all probability, the user won't understand and instead just think "why does my phone have such crappy battery life?"
I can see the complaints filling Apple support lines, forums, and AI now...........
The logical extension of that would be that users should be banned from doing anything on their phone that would run the battery down, say like playing music, videos, surfing the web....
The logical extension of that would be that users should be banned from doing anything on their phone that would run the battery down, say like playing music, videos, surfing the web....
The logic is that people will think they aren't in an application - so it won't affect the battery life - and then get pissed when it does.
Maybe that's true; maybe it's not. Clearly though, that's the general logic Apple is going with, and I don't think that it's without merit.