1. While I agree with most developers that Apple has room for improvement, I think we should take a step back and realize how much of an improvement the iPhone has made mobile developers from a couple of years ago when the carriers were in charge of mobile applications.
2. I think the solution to the iPhone fiasco should be for Apple to hire more reviewers and allow developers to pay more money so that they can buy a faster turnaround time. It doesn't make sense for me to wait 2-3 weeks for another shot at the review process because I placed a bad keyword in the description.
I strongly disagree with your conclusion. Both smack of 'religious' thinking. Your point 1 is essentially 'be thankful to the merciful god who has ended the drought'. Your point 2 doesn't solve the problem, it just throws more priests at it.
The solution is to open the platform to all developers. Imagine if Microsoft had vetted every DOS and Windows app, or if we had to submit Linux apps to Linus for review.
Yes, PG makes the point very well. Apple thinks of themselves as ensuring quality, when in reality they are having the exact opposite effect.
What they need to do is just let all apps through, and make it easy for customers to report problems, and then Apple can proactively pull apps that have too many problems. They could do that at half the cost and have much better overall quality, to say nothing of the developer good will.
Of course, then Apple couldn't screen for the things that they care about but that users won't report.
For example, applications that use Apple/iPhone imagery wouldn't get reported because users don't care about the dilution of Apple's brand.
Likewise, applications that encourage the user to do things that might damage the device (swinging, throwing, or dropping) wouldn't be reported because the device is broken -- and the user will probably try to get it replaced under warranty rather than admitting that they did something stupid with their phone.
Fair point, but they can do that anyway. Also, it would give them an incentive to actually review things in a timely manner.
The other thing is they could keep the existing process for everyone's first app, but once you are a trusted developer things should be smoother. That would eliminate most of the pain.
If I create a website that tells you that you should play the (already existant) Super Monkey Ball app by wildly swinging it around like a monkey, should Apple blacklist my site from all iphone users? (Bonus points: if not, why, and how is it different from your example?)
The question you should ask is do Apple customers want Apple to protect them from those sites?
I work with non-hacker computer users all day long and the answer is emphatically that they do want Apple to hold their hand and protect them so they can get their work done without having to fight with their machine. They want a padded room where they don't have to constantly worry about bandaging themselves up from being accidentally impaled on some spike around the corner.
Users definitely want a controlled ecosystem that is somewhat sanitized and they are willing to take it at the expense of having the latest greatest features, and also at the expense of paying more.
It's not a question of whether they should reject certain apps, but whether they can. Under the current system, Apple can reject applications that encourage you to throw your iPhone. And the ability to do this is definitely something Apple wants, as they currently use this criteria to reject such apps. This ability would be diminished under dasil003's proposal, so it would be harder to convince Apple that such a system is a net win.
Imagine if Microsoft had vetted every DOS and Windows app
Or, hold constant that Microsoft didn't vet DOS/Windows apps and imagine that every DOS/Windows machine had access to a cellular network owned by a some other company.
I agree that the review process is completely broken, but I don't think the solution is as easy as having no controls whatsoever.
> , hold constant that Microsoft didn't vet DOS/Windows apps and imagine that every DOS/Windows machine had access to a cellular network owned by a some other company.
Well most windows machines do have access to a network controlled by someone else. And with the proliferation of cellular usb accessories more and more windows machines do have access to a cellular network owned by some other company.
True, and about ten million of them are estimated to be in the Conficker botnet, another half a million in the Kraken botnet, etc, etc... I'm definitely not saying that Microsoft should have been vetting programs. I'm saying that cellular platforms may not yet be to the point where unfettered access is safe. The software on cell phones tends to favor being small at the expense of all else - probably including safety.
Conversely, having a horrible train-wreck of an approval process like Apple does clearly doesn't mean you can't have unparalleled success either. So I guess we're back to square one.
Umm yes. But nobody seems to be arguing that. The original commenter implied that without vetting the applications, the carriers networks would be in danger. But that reality already exists on plenty of other platforms (even one by Microsoft) without any troubles. The success or failure of the platform is not in question.
Unpopular platforms rarely have problems with third party software, regardless of any approval process.
It's possible that if Windows Mobile had been as popular as the iPhone, then the carriers _would_ have started to see a big problem with malware ruining their networks.
I've owned two Windows Mobile phones over the past 5 years. Both allowed me complete access to install any third-party applications, in spite the fact they were on third-party cellular network. Same for Nokia. No application vetting whatsoever. Mobile platforms tend to separate critical functions in the radio from what a developer can do with the exposed APIs.
Of course neither had an app store, but there were no controls in place for these platforms, and the cellular networks are still up.
Apple's actual reason for the approval process is quality control. And by quality control, I mean everything from ensuring a lack of bugs to a polished interface and, last but certainly not least, lack of malware.
Apple wants people to actually buy apps — imagine that. And how do you accomplish that? Make absolutely sure that users don't for even a second think that the app they're interested in might be crap or malware.
Nothing kills spontaneous app shopping like a fear of malware, that's what Apple wants to make sure stays out of their garden.
I keep seeing this notion of opening the platform brought up here. I'm having a hard time visualizing how this works out.
Does Apple continue the overhead/cost of the app store? Do they have a giant disclaimer that they do not support or condone the applications, take no responsibility for any damages, etc? Do they still act as the payment gateway? How does this impact Apple's brand and the consumer trust of the product?
Why is it that mobile phones with open app development have not taken off even with years and years of head start?
What is Apple's incentive to do this? Can they make money on a phone that allows this sort of development?
I really think there is a lot more to it than just "open it up the world deserves to be free" and we're not talking about it. Why is that?
I think the App Store would do just fine if the platform were opened up. Look at the original App Store for music; people had the option to get music from other vendors (or public domain or pirated) as MP3's yet it's convenience and simplicity made it compelling for many users.
I would think the same thing would be true for apps. Many users would continue to use the App Store because of the convenience and the added trust that their verication process provides.
their insentive is that they are purveying a platform. What made dos and windows great was anyone could write for it so everyone did and they had all the apps. Windows and dos suck, but if you wanted to work or play games, you bought the platform anyway because all the app were for it. Customers are like sheep and go where the best apps are, not the best platform. Apple sells a platform. We create the apps. They want the best apps they must open it up so we create the best apps for them. If its easier to develop my app for another platform, I will.
They make money off selling the phone. That apps sells the phone, not the other way around.
Before Android, there was no phone platform with open app development, JavaME and Symbian require a code signing certifiate (at about $300 per year) just for running your own code on your own phone in an acceptable manner. Symbian seems to have opened up a little bit in the last few months with free online signing for your own IMEI, but it is still very little, very late.
They don't - you can run basically anything you want on JavaME without code signing. The only difference is that you can't set a permanent "ok" for some actions without it (that depends on the phone model though).
It's pretty easy - just remove the entire manual approval process and the platform would be "open enough". The problem is that developers cannot iterate, and large problems take forever and a day to plug. Both of these problems are caused by the gigantic (and somewhat arcane/black-boxy) manual review system.
Apple can continue to charge their 30% cut, they can still be the only gateway to get apps... but at the very least you can submit things and have them available to your users immediately.
From my POV the easiest fix for a situation where lots of dumbass things are being done is simply for people -- in this case, Apple -- to just STOP doing those dumbass things.
Duh! (<-- hyper-intellectual argument I know)
Reminds me of an old Bob Newhart comedy routine about a rather blunt psychotherapist. His patients would come to him and whine about some bad habit they had, etc. And they would ask him, "Doctor, what should I do?"
He would think for a bit and then raise his hand with a friendly smile and say, "Stop it."
The patient: "What?"
Doctor: "Stop it. Stop doing that."
"Uh, I don't understand. Should I---"
"Ok maybe I'm not making myself clear. Sometimes that happens. So I'm going to say this again, very carefully, and I need you to pay attention."
"Yes, Doctor. Go ahead."
Then he would get up and yell, "STOP ITTTTTT! JUST STOP!"
Then hand them the bill and say the session was over.
There's a big difference between a legal disclaimer that no one reads and a marketing disclaimer.
Apple unofficially accepts responsibility for the AppStore apps. They don't vouch for their quality per se, but they do vouch for the fact that they won't wreck your phone.
The same can't be said for apps on an open platform.
Hackers love open platforms but users flee them because the experience is painful.
Hackers love open platforms but users flee them because the experience is painful.
Very well said. The developers the app store is designed for are the boring, careful, professional developers who create polished, shiny, dependable apps. And that's what most users want. They want freedom from fear -- freedom to search the App Store and download whatever they find without without worrying about their level of sophistication. They want Disneyland, not a bazaar in Cairo. They want new Times Square, not old Times Square.
As a matter of pride, developers and early adopters refuse to acknowledge this factor. They pride themselves on their savoir faire and their ability to safely navigate an uncontrolled software ecosystem. The image of Apple users is carefree, self-assured, and adventuresome, and consumers can't feel that way in a place that is wild and unpredictable. They need Disneyland.
> Imagine if Microsoft had vetted every DOS and Windows app
We associate the BSOD with Microsoft software. However, in the majority of cases, the bug is in someone else's code or is a hardware problem. These days it drivers, but in early Windows (pre-NT), applications could cause the system to die.
I suspect that Apple are vetting to avoid bad apps from tainting the perception of the platform. The platform is what they care about, "like Google cares about search".
If an app is buggy and fixes or new features don't turn up the end-user blames the app vendor. If the device crashes, the end-user blames the platform vendor. Those things can stick; witness how the BSOD has influenced perception of the Microsoft platform.
Avoiding that is a reasonable thing for Apple to want to do. However, I agree that the way they are doing it is probably counterproductive.
Your first point is a bit like saying we should take a step back and be glad we're only being imprisoned instead of being imprisoned and beaten. Perhaps we should be happy about any improvements, but the situation still isn't very good. Android and Maemo both treat developers much better, and while I suspect Maemo will remain a niche platform, Android most certainly will not.
1. I'eve mixed feelings about that. The idea of a store was great because it was a great marketplace without tricks to get inside, as it's just a simple as paying 100$ (and lose two weeks understanding how the whole process works...).
But the review process is not the part of the App Store that made it successful, nor the fact the applications are so limited and can't use APIs outside a strict list.
2. This is not something you can fix with more reviewers... it's not just a matter of time, but there no way to create an objective review system, at least if you don't limit the review process to macroscopic stuff like "the app does not work" or "there is a huge disney logo", but in big companies you can't do things like this. If you have got the review process then even a 3 pixel logo of something remotely copyrighted will stop the process.
Also, the more reviewers you need, the less qualified you get, and it requires to be very sensible to handle well the review process. I don't think this can work. Jeff FooBar will simply read all the rules and apply them without the ability to figure if it's really applicable in this particular case. So like it happened recently if there is a program to connect to your mac, and it shows an icon accordingly to the model of mac detected, and there is a 10x20 pixel mac os x default aurora background, he will stop the application.
1. A couple of years ago, I had a Windows Mobile phone and tonnes of applications. While it wasn't a great phone, it was a still a pretty good computing platform. A couple of years before that, I had an SE smartphone running Symbian which had fewer apps but was still open (I even developed a few). For smartphones, carriers were no more in charge of mobile applications then as they are now. In fact, in Apple's case, the carrier (AT&T) has more control than they do on blackberries or WinMo phones.
2. The review process is almost exponential, every week you have more apps and updates to all the existing apps. Maybe Apple is hiring more reviewers; they might have to just to keep up. Having a paid review tier just means that big developers get a 1 day turn around and indy developers get the left overs.
The App Store is only viable because Apple is protecting it as a crown jewel loss-leader. If the Store were spun off into a separate company (not a subsidiary) that had to be profitable on its own, I can imagine the policies changing for the better rather quickly.
Unlikely. 30% is already pretty high, probably more than any startup would have been able to credibly command. It's another instance of the lack of choice allowing Apple to dictate whatever terms they like, however unfavorable they may be.
I don't think it's a protection thing, and loss-leader isn't entirely fair. The App Store makes money, there's no question about that. It's just that the profits from the hardware make the App Store money irrelevant. Apple almost certainly makes more money from the Google Searches in Safari (maybe even just in MobileSafari) then they do from the App Store, figures in the hundreds of millions. Compare that to the iPhone profits which are in the billions already.
Paul captured my whole feeling about the App Store matter, especially about buying Apple products. Now I feel like I'm doing something wrong. I still like the products but I no longer like the company.
Today my small team of developers submitted the first "toy" we released just to test how the approval process works. Let's see if we'll have some bad experience as well.
Faustian bargain? Assholes? Evil? .. really, if this is the most serious accusation of "evil" one can level at Apple then it isn't really going to affect my buying decisions. It's not like they're dealing in small arms or manufacturing cluster bombs. If you step back and think about it all Apple is doing is stuffing up their own app store, which can be classified as monumentally stupid and short sighted but not really "evil".
Do you see my point? To anybody outside the app development community it's going to look a little bit "self important" for developers to be using such strong language and talking of boycotts over something most folks would agree is not evil.
I agree what Apple is doing is stupid, in the long term the app store is going to be polluted with crappy apps and they're approval backlog is going to be rather daunting. I think strong lobbying from the development community is in order, but it takes conscious and deliberate inhumanity for me to label someone "evil".
Yeah, but it's Paul's point that it's the developer's opinions that matter, hyperbole or not. Microsoft didn't get into the business of operating systems until Apple kicked them off of theirs. If Apple makes it too hard for developers to write software for them, developers will go to the next best thing, even if it's DOS.
There is more than one definition of "evil" - in one case it means "harmful or injurious" and this is what I think most people mean when they say Apple is "evil", not that they really think there are people inside of Apple thinking about how they can deliberately screw developers over in some amoral way. Apple is definitely acting by this form of "evil" towards developers by harming their ability to serve the customer, and because developers feel unjustly harmed, developers feel they are justified in using this strong language.
I think it's reasonable to make such a charge if "their app store" is in effect "The App Store". This is like saying that it's not evil to remove freedom of speech in America. I mean, it's only stuffing up "their country".
Sorry but I believe in a religious way that an hardware vendor should not have the power to enforce what software can run into a device. Like a bike vendor can't force you to only use your bike in a limited number of streets.
That metaphor is wrong. It isn't illegal to jailbreak an iPhone, it just voids the warrantee. You can run any software you like on an iPhone.
A company should have the right to control the user experience offered for a device that it designed and manufactured. That will mean denying a third party's right to bypass those controls.
The user has the right to do anything with the device once they've bought it.
My vote for a truly free hand-held platform is the n900[1].
It's beautiful, clean and comes with with Debian based distro, Maemo.
My opinions about apple were never positive, probably because I'm only 25 and did not program in the 80's.
I've only saw apple as a manufacturer of shiny, well designed rich boy toys, but that is probably because I live in Brazil, where only rich people have it and they think they are 'computer people' because of it.
I was always more influenced by the open source community, and apple's record is far from shiny on that aspect.
I've got this baby on preorder, can't wait to see if Maemo lives up to the hype.
Personally I've never been an iPhone fan either purely because you can get phones with far, far better technology for the same price. iPhone wins hands down in UI right now (I still hate touchscreen-only phones though), but that really won't be an issue for long with Nokia/Samsung/SE/HTC working double time to improve their OSes.
You know on BlackBerry AppWorld each submission of an update costs you $20 AND goes through a lengthy approval process. (you need to purchase 10 submissions for $200 at a time). Oh there's a bug in my app? I could fix it in 5 minutes, but too bad..
There's a fundamental difference between BlackBerry and iPhone here, though: You don't have to use BlackBerry AppWorld if you don't want to, you can make your application available directly from your own website. Furthermore, AppWorld only takes a 20% cut: I think getting another 10% of the gross revenue (over what the App Store charges) should be worth a flat $20 administration fee to you.
Speaking from personal experience, their approval process is not lengthy at all. On their site they say 8-10 business days and sure enough I got approved on day 8.
I was at the BB Dev Con last week and their tech lead explained the approval process: "they load it, make sure it doesn't crash the phone, then sign off on it."
My biggest problem is that it's a half-assed review process. Neither is it an open platform nor is it a relatively clear and thorough review process like you get on the gaming device platforms (Microsoft, Nintendo, and Sony).
I made three applications (only one that was popular - WiFinder) for the AppStore. Every time I interacted with reviewers, either by e-mail or phone, I got the feeling they had no idea what they had signed up for, and had not thought out beforehand how to deliver on the promise of only having quality applications in the AppStore. Which is a shame because it's an old problem.
Some Nokia devices have a TV out facility that lets you see the screen output on an attached TV. Coupled with a Bluetooth keyboard you have the beginnings (I know it isn't perfect) of an acceptable input and output arrangement. Then take a text editor and something like Python for Series 60 and voila - a mobile development device. I've already got Putty (SSH) running on my phone, so I can do server side development via that.
Yea, my Nokia N95 (built in 2007) has this... it works perfectly for showing videos, etc. Mobile mfgs. are starting to build 720p HD-ready devices (ala Samsung Omnia i8910) but there's still tons of bugs and it's all very beta. Give it 2 years and we'll have phones outputting quality 720p, they're already recording at that resolution. With the latest tech like Qualcomm's Snapdragon (1ghz chip) on phones like the HTC HD2, I wouldn't be surprised if you could get some decent dev-work out of it.
A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It's used by thousands of people all over the world all day long.
It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run in 12 seconds.
But it took 6 days to get through QA (while the users continued to suffer). QA's biggest complaint? I indented 4 spaces instead of the (unpublished) standard of 5 spaces.
Of all the things I have to deal with, nothing pisses me off more. Software QA is becoming more and more like TSA security at the airport: illogical, and obviously so. Last year, flagrantly unacceptable code was promoted without question while its replacement was held up on a meaningless detail.
I got the feeling from the programmer's quotes in this essay that the same thing is happening at the app store.
We programmers are a funny lot. Make us struggle for business or technical reasons and we adapt beautifully. Make us struggle for something stupid and we just get pissed off and do something else. What a pity.
Not that the indentation complaints are valid, but the fix should definitely go through QA while the users continue to suffer. While I'm sure it works on the developer machine, it is much better to have a program that takes a long time and works right than for it to give incorrect results to users, or make a different part of the application stop working.
If the feature was really critical and important, QA should find a way to expedite the verification, but it should never be skipped in order to ship the fix faster.
I've seen lots of software that's gone through QA but didn't work. Ever use Microsoft Windows?
QA is important, but determining how many spaces a line of code is indented is not QA. That is a code review, which is important, but not critical. There should be automated acceptance tests, so that new releases can be shipped immediately. (It's also worth noting that stuff like indenting, naming conventions, etc. can be automatically checked at checkin time. See Perl::Critic, for example.)
If there is some feature or corner case that the users test but isn't in the acceptance test suite... well... yeah, the software is going to be unreliable. So don't do that. Write a test.
(I worked somewhere with a QA department once. They didn't like it when the programmers wrote tests, because they felt their job would be threatened. It was true, so we were asked to only write unit tests; no "integration" or "acceptance" tests. I quit a few weeks later.)
I did QA for years (8+) and would love to have developers write a test. Specifically NOT unit tests, but the harder more interesting one. I think it happened once. Or, was it twice?
Bullshit, its attitudes like this that lead to crap software. Developers should work with QA to find the bugs, they're not "QA's bugs" they're OUR Bugs, we're a team, right? When you change a component you should also be able to write a simple manual test to prove the functionality works you should also perform this test yourself.
As an optional if the QA people are good then describe what else might be effected by the code (if you edited a generic component). Good QA people will run your test, work out their own variations and also check other areas.
Like all "lost job" situations, it is a myth. If you write good Integration tests, QA's job should be to find gaps in them, test the really weird edge cases only a human can come up with and perhaps provide usability feedback.
Any decision made that promotes inefficiencies to "save jobs" puts the entire company in danger.
That's only true some times. Unless the data is mission critical, or you introduce a really major bug, the company in question could be losing customer's and / or significant revenue due to the slow down of the application.
I'm not saying you're wrong, I'm just saying there's no hard rule on this. I've had to push code many many times without any outside testing and while occasionally it's been detrimental (but fixed quick, because I didn't have to go through QA), the large majority of times has been beneficial.
A large and formal QA process can kill a product / project just a quickly as cowboy code.
As amusing as that statement is (and I think you meant it jokingly), I definitely have to disagree. There's just too many different developer styles to say No developer. Personally I like to ship quality code and am pretty anal about it's quality as well as it's interface, so you can bet I refactor my code a lot... and I mean a lot.
(In fact I just refactored this comment to fix a spelling mistake... but I published it without writing any automated tests, or running it by QA... somehow I don't think many people noticed)
I've always been treated well by QA. I'm sure there are problem QA departments out there but I doubt they are the rule. It's amazing to me that the parent got down moded for supporting the task of QA.
I think people are responding to the suggestion that in general developers will subconsciously protect their ego by willfully ignoring flaws in their own software. That is just tremendously offensive to any real hacker, and if it were true the world of software would be a pale shadow of what it is today.
I don't think it's a slam on developers - I've hit and played outfield, and I know what each side feels like. It's not that developers wants to ship bad software, but haven't you ever avoided running a test because you're afraid of opening a can of worms? QA wants to open that can. There's a perverse glee in seeing all the worms get out.
When a new bug is found (a good one, not BS indentation) then QA has a justifiable joy in finding it before it got to the customer. The developer may also be devoted to quality, but doesn't your heart sink a little when you see a new bug? Overall you both want to ship good product, but your minute-to-minute motivations are just different.
No, QA is your double-check, you shouldn't rely on them as we're all just humans and we all can make mistakes. You should still test the code yourself and think of ways to break it. Although I will agree that developers are blind to some bugs (which is why you need the double-check).
I find when this stuff happens with QA teams, it's almost always a case of protecting turf.
When no one is looking (the first, buggy, submission is made), they will do the minimum necessary and approve it, often quickly.
Then, when everything goes to hell, all eyes are on them. The developers submit a fix with the note "this needs to be approved ASAP to put out fires"... the QA person resents being told what to do, and suddenly feels compelled to justify his job by finding anything and everything that could possibly be considered 'wrong'. There is also the issue that things like indentation are more visibly 'wrong' than obscure bugs that only show up in production environments due to the way database replication is set up.
Now, I'm not saying all QA people are like this. I've worked with some downright awesome QA people before. But awesome QA people don't reject things for spite, and usually don't stay in QA long before moving up.
It is more like there is a problem with an important application, everybody gets the blame. The developer, QA, PM.
So everybody wants to make sure it goes well. The developer. The QA.
The QA doesn't always understand all the contraints put on him, that he has to follow. For example, if this is a fortran program, the indenting will cause it to break. So rather than second guessing every step, he follow every step of the book. So if there is another problem, he doesn't take the blame.
No, at some companies people really do have the QA department ensure "code quality". After all, it's Quality Assurance, so they must know about code Quality!
The best QA teams have developers and security people in them exactly for this reason. Quality is not what the users see - it's a correct implementation of what the specs say, built upon a series of basic assumptions that apply to all software they ship.
Treating QA as a step after development is a mistake that causes endless suffering to users.
It seems to me like treating QA as developers who are not allowed to write code, but can criticize it, would tend to result in a situation exactly like the one described.
Indeed QA is not a step after development, but I'd argue that encouraging developers to become better at QA themselves is a more effective approach than having non-coders inspecting sources after the fact.
Value - stuff should work after it's been through them
Costs that I've seen
- more stuff doesn't get done/fixed because of the delay time associated with QA
- things don't get scheduled because of lack of QA bandwidth
- additional specifications required in order to go through QA
- programmers / PMs worry less about catching bugs because they feel it'll come back from QA
When is it better to QA something rather than just measure when it's broken? Everything we do goes through QA but I'm sure most of it is a net loss.
Anyone have a good way of knowing what to QA and what to simply monitor?
Agreed. The last company I worked at we had some similar idiocy.
We had a backend process that connected out to a network and did some things. However, the network it connected to changed their protocol, so our backend process was broken - didn't do anything - completely non functional.
We created a fix, but had to wait for it to go through QA for ages. What's the worst that could happen? It doesn't do anything like the current version? It wasn't even a massive update. Maddening.
The worst? Data Loss, or corruption, which is worse than "not working".
Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.
Again, not justifing it taking ages, just saying there's never an excuse to skip QA.
You indented with spaces instead of tabs!? Just kidding of course, but the QA team might have been on the other side of that holy war. I'm going to have to start using your TSA parallel though... it's so painfully true.
We programmers are a funny lot. Make us struggle for business or technical reasons and we adapt beautifully. Make us struggle for something stupid and we just get pissed off and do something else.
This is the best YC quote of all time. Thx, edwin!
As Moore's law marches on, it's inevitable that the computing power needed by Joe Sixpack will fit into smaller and smaller packages. The rise of the desktop, then laptop, now netbook. Each iteration takes less time than the previous one. That asymptote will soon - a few years at the outside - hit the iPhone/PDA form factor
Apple must understand this, and they can't possibly believe they'll be allowed to maintain this sort of dictatorial control over people's primary general computing platform
I wish Amazon gets into the handheld device business.
They clearly understand consumers, software, infrastructure & user-experience. They missed the boat with the ipod, here's a fantastic opportunity to do something about it.
I suspect because it's difficult for them to technically do so. They would have pulled the GV Mobile app in an instant, if they could have, but the iPhone OS doesn't have this capability. The Kindle does.
Most of Apple's policies handling the app store make me somewhat believe they wanted their original plan to succeed, namely, making developers write web applications and not opening up the iPhone to native development.
Agreed. I think there's at least a 50% chance that the original plan was a console-like model where the only native apps would be from Apple and hand-picked partners. The popularity of jailbreaking forced their hand, because if unlocking became common it would ruin their cozy relationship with the carriers.
I agree with the primary point that Apple is making a mistake in not treating developers well.
However, I think that the essay misses a couple of points.
1. The essay rejects the notion of an "intermediary" or a "software publisher". However, it fails to appreciate the fact Apple has opened up the mobile app market to developers and eliminated far worse intermediaries (the walled gardens of carriers). This is a huge order-of-magnitude improvement.
2. A lot of developers do release badly-buggy apps out there and then end up "blaming" the Apple review process for their customers dissatusfaction. While I agree with the launch-fast-and-iterate approach, I don't think developers/companies should use that as a license to release poor-quality crashing apps. Cutting/postponing features to launch the app quickly can be a good thing, not testing the app and releasing an app with crashing bugs is not a good thing.
---
I don't expect Apple to throw out the review process, but I do hope that they improve the review process. A simple/easy improvement would be to show the latest queue ranking of apps that are waiting for review. That will go a long way towards reducing the "ongoing karma leak" that pg mentions.
Replying promptly to developer emails about app-store rejection will also help. Setting a limit of n apps for a $99 license may also help Apple cope with the incoming deluge of apps
1. Carriers never had walled gardens around smartphones. Apple didn't invent smartphones, they've been around for years before the iPhone was released. In fact, the carrier (AT&T) has more control than they do on blackberries or WinMo phones.
2. I'm not sure what you're trying to say here. The review process exists so developers are already doing their best to not be rejected and Apple is rejecting anything badly-buggy. Bugs still escape that process, it's inevitable. Fixing them should be easy and quick, but it's not, and Apple is entirely to blame for that.
Though I can't marshall any evidence to support this claim, it was specifically not my impression that Apple was a company pro developers loved working with before the iPhone.
In high school, I thought that the CodeWarrior IDE (which was, as far as I knew, the dominant development environment) was absolutely terrible. I'm not sure how good my judgment at that time was.
That said, with OS X they really became a lot more developer friendly just because they adopted a UNIX base. At this point, I'd say they're the default platform for ruby/web development. Look at all the rails job postings for small startups promising 30" Mac Pros, etc.
Yeah, I have terrible experiences with codewarrior as well. I had one programming class in the late 90s that required macs and boy did that make me hate macs with a passion.
But I dont think it was purely a codewarrior issue. The overall apple OS at that time was simply terrible and 10 years behind windows (i wont even count how far behind unix they were) -- they still could not get multitasking to work right. Which meant that any pointer error causes your computer to hang. And when you are coding for a data structures class in C all of your errors are pointer errors.
So I am sure a lot of developers abandoned the mac platform around those times, but maybe many of them are coming back now.
Fully agree. I recall in particular reading John Carmack a few years back talking about how he was glad Apple wasn't as dominant as Microsoft, because they were far harder to work with.
I wish I could remember the quote well enough to search accurately for it.
Mac developers mostly did (and still do). If you're developing anything other than Mac applications, you probably don't know a lot about what it's like either.
I think the "can't marshall any evidence to support this claim" is pretty critical here, because the vast majority of developers who actually write software for the Mac have loved it since OS X came out. They've loved Cocoa and they loved that the IDE and development tools were made free.
And while there was a dead period due to the technically deficient underpinnings of the late Classic MacOS, before that, the Inside Macintosh days, I hear folks loved programming Apple too.
After having been deeply involved in the Mac dev community for the last 10 years, the implicit claim that Apple is a company pro developers do not love working with sounds, frankly, a little bizarre.
I make Mac apps for a living and have, over a few years built up nice relationships with Apple. In spite of only being a small, not US-based, company (11 people now, but only 5 when we won our first Apple Design Award), it was never hard for us to get noticed by Apple, or to get in touch with the people at Apple we needed to talk to at any given point.
Our first app was built using 'unsanctioned' technology, PyObjC (before PyObjC shipped with 10.5); the app would have never seen the light of day on the iPhone, but then again, we would never have built it in PyObjC for the iPhone to begin with. Everyone we've ever met at Apple has been supportive from day one, and we owe a lot to many of those people.
We have not shipped any iPhone apps, so I can't say how I'd like that, but as a Mac app developer I love working with Apple.
I think there might have been a difference between Mac-only programmers who, it could be argued, were leaving a lot of potential money on the table by not developing for Windows and therefore must be doing it mainly for love of the platform or the company (remember all the Boo's Steve Jobs got when he announced the "investment" from MS in Apple?), and developers who's main product was on Windows and who, perhaps reluctantly, also had to support a Mac version.
This is a very developer-centric view, though. For users, the app store is great - tons of applications, and they're easy to find, buy, and to install. The approval process, for the user, makes a better overall experience, increasing the overall quality of available apps. For each bugfix waiting for approval there I'm certain there's lots of buggy apps being rejected, and for each anedocte of rejection due to using the wrong icon or such nonsense, there's lots of appropriate rejections due to unstable apps.
Obviously without good and satisfied developers those benefits are moot. I'm certain the approval process needs to be [improved/changed/redesigned/removed], and maybe some kind of sanctioned jailbreak should exist where more advanced users can manually install third party apps, but I do believe the App Store itself is a good thing when you you look at it from a user perpective.
I don't think the claim saying that "Apple doesn't understand software" is correct.
Apple do understand software.
You cannot release Mac OS X, iLife and other jewels without understanding software.
Also Mac developers jumping off the iPhone bandwagon are not jumping off the Mac plateform.
For the iPhone, Apple tried a different model that nobody really tried before.
They indeed have a broken store but the previous models on other platforms never worked. The most successful one before was for the PalmOS and it wasn't over the air.
However Apple always been an arrogant company. With their customers, their providers and their developers.
The climax of this arrogance has been reached with the iPhone eco system (certainly helped by the arrogance of the mobile phone operators).
And for many it is not sustainable.
But anyways, who really cares?
Apple can open the doors of the store overnight.
It wouldn’t have been the first time they do one thing making you beleive it was the only way and then suddenly change in the opposite direction.
That’s the strength of Apple: they can change.
Not only they can change but they usually know when, with what, for who and at which price.
I never realised the arrogance was a trade mark of this process though.
Note: I don't mean being evil by being arrogant.
Apple has always treated third-party developers with suspicion. The developer website is only accessible by creating an account and agreeing to their license agreement. They churn through and deprecate APIs comparatively fast. They will quite happily steam-roller over third-party developers by adding competing features to the OS:
http://en.wikipedia.org/wiki/Dashboard_%28software%29#Compar...
None of this is new, the only difference is that there's now a release bottleneck that requires Apple's approval, and there's a lot of developers new to the platform.
The thing is, this is part of Apple's culture for a reason. Steve is an obsessive control-freak when it comes to a great user experience, and third party developers are seen as a threat to that. Microsoft has always been a great company to deal with as a third-party developer - they value their ecosystem, put effort into free documentation and solid IDEs, and rely on outside developers for key applications. The trouble with this comparative openness is that you end up with 800 pieces of software written by different companies fighting it out on your desktop, leading to crashes and inconsistent UIs all over the place.
I think Apple is in danger of screwing up a great opportunity with the app store, but this way of operating is in their DNA and it won't be easy to change. Despite what the geek consensus might be, the record shows they've made a lot of money in the past whilst ignoring third-party developers.
> The trouble with this comparative openness is that you end up with 800 pieces of software written by different companies fighting it out on your desktop, leading to crashes and inconsistent UIs all over the place.
And that's a bad thing because? Who has the mainstream OS now with over 87% market-share? Even popular cross-platform applications that were first available for Macs (like Adobe Photoshop) are now more optimized for Windows.
Microsoft has always been more open ... you can install Windows on any hardware you want as long as it's compatible (and most hardware is, with the notable exception of ARM-processors).
The developer tools where a lot more competitive because Microsoft allowed competition from the likes of Borland. And the Windows API was free to use (as opposed to OS/2 for instance). And for end-users ... Microsoft has always been committed to backwards compatibility (at least for popular applications).
Microsoft can be called "evil" yes, because of their aggressive tactics regarding competition. But imagine what would Apple do in the same position ... and it's kind of ironic that many developers choosing openness went to Apple for that.
Apple makes money, yes, but they were on the edge of bankruptcy ... they should've learned a valuable lesson then (besides keeping Steve Jobs as the CEO).
"you can install Windows on any hardware you want as long as it's compatible"
Sorry, I had to laugh.
Part of the blame for Itanium losing the 64-bit bandwagon could be pointed to Microsoft, for not having Windows ready for it when it became available. Or for delaying the launch - it's silly to launch a processor without an OS to run it on.
Having Windows support for your hardware is paramount to any desktop computer company since the early 90's (with the notable exception of Apple). Alpha, MIPS and PowerPC (as in PReP) desktop systems are not dead because x86 systems were a better price/performance choice: they are dead because Microsoft pulled the plug on NT for them (and Linux was not ready to take its place at that time). That's also why all our computers are remarkably alike from the inside. It's not that Microsoft is open - it's that they have computer makers cornered.
Today I can get a non x86 computer and expect all my userland to work (with the possible exception of Flash, Skype and parts of Eclipse). I could not do that in the 90s.
The Itanium is not an expensive server chip because Intel cannot build an Atom-like processor with the Itanium ISA (heck - it must be easier than do it with the x86 ISA). It's an expensive server chip because it won't run Windows 7 and Office.
I see very little competition in the development tools in the Microsoft space these days. Tool makers know better - if they make something that competes with Visual Studio, Microsoft will come after them in the next release cycle and it is not worth the pain to fight them. That's why every non-Microsoft development tool around is built for a niche. Or is free, a case where Microsoft will not be able to go after you. That could be a reason for the free language explosion we are seeing.
And thanks. The Psystar imbroglio is a statement of how evil Apple can be about competition these days.
It even seems that after stopping attracting the best and brightest, they started attracting former Microsoft minions...
You seem to think I'm arguing that Apple's approach is better than Microsoft's. I'm not at all, just pointing out that there's internally-consistent reasons behind Apple's culture of preferring tightly-controlled, closed systems. The lesson learned from that brush with bankruptcy was that the cloned-hardware approach degraded the user experience.
Steve seems to think that the benefits of closed systems (standardised UI, fewer crashes) outweigh the costs (more expensive, less software). I don't have to agree to recognize that he's making a rational trade-off.
Since when was Apple's reputation with developers great? They've always been capricious, flighty and controlling - not what you need in a solid platform.
I am about to show my ignorance of developing for the iPhone, so please forgive any incorrect assumptions and mistaken conclusions.
It is my understanding that apps can also be installed directly from third party websites... If so, is there a way to create an app for the App Store that is a shell to a website where a conglomerate of listings can be offered? It seems this would give the value of having everything fairly easy to find (one extra click) and yet get out from the management of the App Store for all but the original shell app...
It is my understanding that apps can also be installed directly from third party websites...
This is not true, and that's the essence of the problem.
You can install software that you've written yourself on your own phone. And there's some sort of deal that lets you give your software to beta testers and let them install it. A year or so ago some clever fellow tried to use this beta loophole as a way of selling an app that was banned from the App Store. I believe they threw the book at him and he had to stop. I haven't heard of that happening again.
You can distribute apps for jailbroken phones, but that is not really a solution.
I disagree with the blanket statement that it doesn't work: for every 10 programmers who cant be bothered to create FOO app because of all the fuss there will be one who does because he can take some market share.
I agree in spirit the system is screwed - but Apple do have a hell of a lot of sway. They have the leading product and the huge customer base (and the cool factor). To a point they can dictate things (and I agree this is bad and we should stop them)
If you want a developer environment that fits in your pocket, look no further than the TI-83 graphing calculator.
Much of my free time in highschool was spent creating games on it. It's extremely easy to develop for (it uses a variant of BASIC), and the menu system is designed to minimize keystrokes, which means you can bang out your code very quickly.
Of course, the platform is very dated: 6 MHz CPU, and a 96×64 monochrome LCD screen! I'd love to see something in the same format, built with modern technology. Maybe the default language could be Python.
The goal would be to have that kind of developer-friendly functionality in a much more powerful and usable form. Imagine having a "phone" with a robust and developer-friendly OS that could wirelessly connect to external displays and peripherals. You'd have a single, compact brick of computing power in your pocket at all times. And if the oft-projected future of cloud services comes to fruition, the device itself wouldn't necessarily have to have ultra high-end computing power or storage.
That's a mobile experience that I'd get excited for.
I spent every calculus class working on various things. My proudest accomplishment was a blackjack game. I implemented drawing routines for every card type, which was really painful given the graphics primitives you had available. So much Line(..) and PxOn(..).
Distribution mechanism was hooking up that cable to your classmates' TI-XX. Maybe iPhone devs should try that.
Go for an HP graphing calculator, then. ARM processor, SD slot, far more powerful programming tools, especially the built-in ones. TI's have BASIC on the calculator, but HPs have an interpreted language, a compiled systems programming language, and an assembler and disassembler all in ROM. And you can run a C cross-compiler on your laptop.
It's nowhere near as powerful as a PDA, but it has a great keyboard (for math, at least) and runs off AAs.
Part of Paul's reasoning depends on Apps being central to the iPhone experience the same way software is central to the desktop experience. I'm not totally sure this is the case. While apps are certainly a major component to the iPhone, are they really the major factor in end-user adoption? With the exception of games, how many killer iPhone apps are there that don't already ship with the phone? The phone shipped for an entire year without an App Store at all. I even read something not that long ago that said the majority of apps sit unused on people's phones after they get them.
Now, this doesn't mean that developers won't want a developer friendly phone, or that Apple is hurting their reputation with developers. I'm certain it has been frustrating to deal with the whole process. However, if 3rd party software isn't essential for the iPhone as a platform, then developer satisfaction moves down a bit in terms of importance in Apple's eyes.
Now, it's clear that games are major for the app store. Games are also a special class of software application that benefits disproportionately from having access to the hardware at a low level. They also have properties more similar to music and movies (incidentally, things the iTunes store is good at selling). Except for the simplest games, they require a lot of up-front design work and investment. It's rare that a released game goes through a ton of rapid iterations to "get it right". Games may still have bugs after release, but in general the functionality they are going to have is there on day one. They also ship with the final sound effects, music, artwork, etc... Games are also probably very unlikely to "duplicate existing functinoality" or any of the other cases where "normal" apps hit barriers. Perhaps Apple has (intentionally or unintentionally) created an environment optimized for game approval?
I'm certainly not defending the app store process, but I just wonder if the software development community has a disproportionate view of its importance to the iPhone as a whole.
You're sort of right, but that's true for all other platforms as well, so it doesn't really tell us anything about the state of app use on the iPhone platform.
The OS bundled ones are the ones people use the most. Across the board.
If I had to guess, I'd say third party apps are just as often or more used on iPhone than on, say, Windows and Mac OS X. Simply because, on iPhone, a lot of web apps out there are used via a special-purpose iPhone app rather than the web interface.
We probably have a different view on what is a killer app. From my perspective: Windows - Outlook Express, IE. OS X - Mail, Safari. I can't recall the last time I fired up "Photoshop, Excel, Quicken, Final Cut" and I bet 90% of randomly selected users couldn't either.
As reliance on mobile devices and their capabilities increase, this could become less of an issue.
It is still a luxury for most people - "oh cool look at this app," but it still comes down to those that can afford an iPhone. I can imagine there are many family squabbles involving parents that bought their kid an iPhone that racked up an App Store bill the parents didn't originally intend.
iPhone is not a business phone overall - and therefore doesn't have "critical apps".
The point I was replying to was that "... third party apps are just as often or more used on iPhone than on, say, Windows and Mac OS X".
I really doubt this is true given the lack of any killer mobile apps. I don't personally consider any of desktop apps in the list I gave 'killer', but fairly sure they've sold lots of computers.
"Killer app" usually means the app that motivates you to switch platforms. For PS3 or Xbox 360, it's the game that made you want to buy the console. For Windows in the '90s, you needed MS Office to get your work done, so you bought a PC. All other things being equal -- i.e. assuming the system has a web browser and the other essential software has cross-platform equivalents -- the killer app is what kills off rival platforms.
When I hear someone say "I wish I had an iPhone right now", it's usually because they're either (i) lost, or looking for something, and want access to Google Maps, or (ii) in the throes of gadget envy. The App Store addresses (ii), but not with any single app -- it's just the idea that there are thousands of fun toys that only iPhone users get to play with.
So there are a couple of killer features, but nothing that can't be replicated on other phones. Not necessarily as well, but that's not the point: without exclusivity, the iPhone will not get the same kind of dominance Windows has.
I too noticed the similarity to the console game development. Usually console game developers have to go through lengthy approval process of the platform provider. Still developers accept that (although grudgingly), since once approved and the released, that will be the end of the process; no more bug fixes; the team dissolves and everybody starts working on the next project. (PC games are different, and certainly network games are continuous development, but console games have this feeling of "done is done").
Part of it may be a byproduct of the way the console games distributed on ROMs or disks. That may change, for consoles nowadays have network connection and can get updates anytime. There's another part, however, that some type of games fits this "done is done" philosophy. Like novels or movies, which you don't expect them to be improved over time.
Well, I don't defend the app store process either, and I believe majority of software should be developed in the iterative process. It's just interesting that games may be a marginal area that has some peculiar properties.
Here's my guess about Apple's thinking. Note that I don't own an iPhone or iTouch. So I don't have any experience with the App Store or submitting applications to it, and can't say that it is or is not working this way but....
Apple wants iPhone apps to "just work" They don't want a plethora of buggy, half-baked, inconsistent apps in their store, because this would diminish the brand. It would be like a typical Linux distribution where half the apps implement their own peculiar UI conventions, crash often, or just don't work at all.
So it is like developing a game. You get one release, one chance, to get it right. It needs to work. Maybe a lot of app developers don't get this. There are published standards about conventions, icons, behavior, etc. The app is expected to be FINISHED and WORKING before you submit it to the store. Don't count on deploying 27 follow up patches and updates to customers -- imagine the chaos if every iPhone app needed updates multiple times. Users (most of whom are not hackers) would, after a while, just give up and abandon the platform.
So, when an app is submitted, it is reviewed, and if it's found to be buggy, or it doesn't work, or it works in an unconventional way, then they don't want it. And they're not in a particular hurry to waste more time on you when you didn't follow the instructions the first time.
I don't know, I'm just speculating. But this seems plausible to me.
I agree. I've recently posted a comment about this in another App Store thread here on HN.
I think this is a good "oh yeah, this is why we do it" argument, but is probably more of a by-product of the review process and less of Apple's original incentive.
A lot of the technical decisions that are made are motivated by business and profit. Not to say that this is a negative thing - Apple is a corporation after all. There are plenty of things I've seen done that are dumb as hell at my employer (at a technical level) but are motivated by external reasons that seem implausible or illogical because the guy writing code is too far removed from the information and the decision.
however, speaking as a guy who has went through the process for 8+ apps so far, that's not the pain point.
It's more about repeatedly encountering dumbass reasons for rejections, and dumbass long delays to get feedback on things that should take about 1 minute, not 2-4 weeks to get feedback on. It's about getting rejected for 1 thing, and then they don't bother to finish reviewing the app and discover the other 2 things that they know they would reject it on during the next submission, so you don't find those out until 2-4 weeks later, and so on, ad nauseum. It's about rejecting for inane reasons (that they can "fix", if they wanted to, and had a brain, by running a small piece of software on, shotgun-style) like 'this config value over here doesn't match this value over there, so please make those the same', or even worse, vague mysteriously-worded rejections, or rejections that contain explicit instructions for "fixing" the issue and then you follow them, resubmit and they reject again.
Dumbasses. I keep coming back to that word over and over again when dealing with their review process/people. We're talking about a company with supposedly billions of dollars in cash in the bank and until a few months ago or so reportedly had what 50 full-time reviewers on staff? (Do the math on what it would cost to even triple that staff and you'll see it's a tiny drop in the bucket compared to the profits that keep rolling in.)
I think you may be right, but I have a couple misgivings.
The year that iPhone existed without the App Store, no smartphone competitors came close to replicating it's core functionality and user experience. I don't think that's quite true anymore, and so I think that the App Store is one of the iPhone's key advantages. Specifically, the iPhone didn't need the App Store to differentiate itself from RIM and WinMo in 2007, but I think it absolutely needs the App Store to differentiate itself from the Pre and Android in 2009.
I don't think there is one killer 3rd-party app on the phone that everyone needs to have, but there could very well be many third party apps that smaller niches need to have. For me personally, MLB At-Bat (live streaming of baseball games) and the Kindle reader are actually the two biggest factors keeping me from switching to Droid. Those applications could easily be ported to Android, but haven't been yet, and in both cases a third party holds the distribution rights for the content so it's not like me or another hacker could replicate those apps easily.
It may not have started out as central to the experience, but I think that it's starting to quickly become just that and Apple knows this or at least they want it to be. So far all the recent iPhone commercials I've seen only focus on the thousands of apps you can get for the iphone - not the iphone's "awesome" feature set. I was looking at a friend's iphone the other day and I saw page after page of 3rd party applications. My wife wanted an iPod Touch because she saw some applications she wanted. Another person I know bought an iPod Touch just so they can run a bird identification program. I don't think these are unusual cases. What's funny is that in the beginning, Apple didn't even want to provide an API for native applications. They wanted all developers to use the Web API. When developers balked at that idea Apple reluctantly laid out plans for native applications.
What's funny is that in the beginning, Apple didn't even want to provide an API for native applications. They wanted all developers to use the Web API. When developers balked at that idea Apple reluctantly laid out plans for native applications.
I wouldn't believe that for a minute. The App Store would have been part of the iPhone product plan from day 1. It's too big, too complex, too strategic, and (yes) too well-executed to be a panicked response to developers' demands.
That's how Apple under Jobs has always done things: major features are not "supported" or "planned" or "offered" or "part of the company's philosophy"... at least, not until they appear out of nowhere one day.
I'm not so sure about that. From an interview with Steve Jobs in the NY Times 1 Nov 2007:
“I don’t want people to think of this as a computer,” he said. “I think of it as reinventing the phone.”
"We define everything that is on the phone,” he said. “You don’t want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesn’t work anymore. These are more like iPods than they are like computers.”
The iPhone, he insisted, would not look like the rest of the wireless industry.
“These are devices that need to work, and you can’t do that if you load any software on them,” he said. “That doesn’t mean there’s not going to be software to buy that you can load on them coming from us. It doesn’t mean we have to write it all, but it means it has to be more of a controlled environment.”
From an interview with Steve Jobs in the NY Times 1 Nov 2007
But the App Store was announced to the public only seven months after that, in June of 2008.
If they did all that work in seven months, my resume will be on someone's desk at Apple by Monday. Seriously. I don't want to compete with any large companies that can move that fast. They win.
No, the only reasonable conclusion is that you can't take Jobs at his word when he appears to rule something out.
Then again Apple already had the libraries for native app development because they were developing apps themselves. They already had iTunes. And you know what? The same people that approve iTunes music submissions also approve App Store submissions. Most of the pieces were in place - they just had to put them together. 7 months doesn't seem too long for a version 1 app store.
Edit: And the question isn't really were they going to have an app store or not - they very well could have been thinking along those lines but reserving it only for software they themselves were going to create or with select partners - the question is whether they were going to open it up to general developers which I think they did not want to do.
I know lots of people who bought in iPhone or or iPod touch because it could run some unique app. It was a different app in each case and in each case it was an app I personally saw no use for, but for them it was a killer app.
Any app that makes someone get an iPhone instead of something else is a "killer app" as far as Apple is concerned, even if it only sold a total of 27 copies and lost the developer a lot of money. So even if the iPhone doesn't have any one killer app, the sheer diversity of apps means there is probably a killer app out there for most people, and that is vital for Apple.
> While apps are certainly a major component to the iPhone, are they really the major factor in end-user adoption?
All the ads I've seen lately for the iPhone are of the "there's an app for that" variety. So Apple themselves seem to think that the apps are a critical factor.
That being said, the iPhone sold very well before there were any apps at all.
There was a story on here (or somewhere) a while back about how 70% of iPhone apps go unused after the first month of purchasing. Couldn't agree more. AFAICT there is no killer 3rd party app for the iPhone. I'd posit that 95% of the iPhone's awesomeness is wrapped up in the following four (OEM) components: 1) Browser, 2) Maps, 3) E-mail / SMS, 4) Visual voicemail. Everything else, including games, is just fluff for most users. Relative to those four, I think the app store is a relatively small driver of adoption. I don't think a lot of people are that wedded to it, and I don't think it makes Apple a particularly large amount of money either. Which would explain why they continue to neglect it in spite of the vociferous scorn of a few programmers and pundits.
Developer relations are central to Apple as a whole. Apples needs iPhone developers, desktop developers, web developers and developers for whatever they do after the iPhone. If Apple creates hostile feelings in the developer community with its App Store behavior, Apple is going to have ongoing problems regardless of whether it needs third party developers at the moment.
Not really :/ They need people developing webapps.
To be honest, I think the appstore is just a stopgap until webapps become mature enough to take over (And wifi is prevalent enough). I wouldn't put too much effort into the appstore, and I don't really blame Apple for being half hearted about it. It's certainly not the future.
283 comments
[ 3.2 ms ] story [ 823 ms ] thread2. I think the solution to the iPhone fiasco should be for Apple to hire more reviewers and allow developers to pay more money so that they can buy a faster turnaround time. It doesn't make sense for me to wait 2-3 weeks for another shot at the review process because I placed a bad keyword in the description.
The solution is to open the platform to all developers. Imagine if Microsoft had vetted every DOS and Windows app, or if we had to submit Linux apps to Linus for review.
What they need to do is just let all apps through, and make it easy for customers to report problems, and then Apple can proactively pull apps that have too many problems. They could do that at half the cost and have much better overall quality, to say nothing of the developer good will.
For example, applications that use Apple/iPhone imagery wouldn't get reported because users don't care about the dilution of Apple's brand.
Likewise, applications that encourage the user to do things that might damage the device (swinging, throwing, or dropping) wouldn't be reported because the device is broken -- and the user will probably try to get it replaced under warranty rather than admitting that they did something stupid with their phone.
The other thing is they could keep the existing process for everyone's first app, but once you are a trusted developer things should be smoother. That would eliminate most of the pain.
The question you should ask is do Apple customers want Apple to protect them from those sites?
I work with non-hacker computer users all day long and the answer is emphatically that they do want Apple to hold their hand and protect them so they can get their work done without having to fight with their machine. They want a padded room where they don't have to constantly worry about bandaging themselves up from being accidentally impaled on some spike around the corner.
Users definitely want a controlled ecosystem that is somewhat sanitized and they are willing to take it at the expense of having the latest greatest features, and also at the expense of paying more.
Or, hold constant that Microsoft didn't vet DOS/Windows apps and imagine that every DOS/Windows machine had access to a cellular network owned by a some other company.
I agree that the review process is completely broken, but I don't think the solution is as easy as having no controls whatsoever.
Well most windows machines do have access to a network controlled by someone else. And with the proliferation of cellular usb accessories more and more windows machines do have access to a cellular network owned by some other company.
I don't think you correctly read my post:) No worries
Too right, I inserted a subliminal "not" after the do.
Apologies!
It's possible that if Windows Mobile had been as popular as the iPhone, then the carriers _would_ have started to see a big problem with malware ruining their networks.
Of course neither had an app store, but there were no controls in place for these platforms, and the cellular networks are still up.
Apple wants people to actually buy apps — imagine that. And how do you accomplish that? Make absolutely sure that users don't for even a second think that the app they're interested in might be crap or malware.
Nothing kills spontaneous app shopping like a fear of malware, that's what Apple wants to make sure stays out of their garden.
Does Apple continue the overhead/cost of the app store? Do they have a giant disclaimer that they do not support or condone the applications, take no responsibility for any damages, etc? Do they still act as the payment gateway? How does this impact Apple's brand and the consumer trust of the product?
Why is it that mobile phones with open app development have not taken off even with years and years of head start?
What is Apple's incentive to do this? Can they make money on a phone that allows this sort of development?
I really think there is a lot more to it than just "open it up the world deserves to be free" and we're not talking about it. Why is that?
I would think the same thing would be true for apps. Many users would continue to use the App Store because of the convenience and the added trust that their verication process provides.
Re: the impact on Apple's brand, see the original article for reasons why the current model doesn't ensure quality.
Apple's incentive is long term viability of the platform. Can they make money indefinitely while alienating developers?
They make money off selling the phone. That apps sells the phone, not the other way around.
Apple can continue to charge their 30% cut, they can still be the only gateway to get apps... but at the very least you can submit things and have them available to your users immediately.
From my POV the easiest fix for a situation where lots of dumbass things are being done is simply for people -- in this case, Apple -- to just STOP doing those dumbass things.
Duh! (<-- hyper-intellectual argument I know)
Reminds me of an old Bob Newhart comedy routine about a rather blunt psychotherapist. His patients would come to him and whine about some bad habit they had, etc. And they would ask him, "Doctor, what should I do?"
He would think for a bit and then raise his hand with a friendly smile and say, "Stop it."
The patient: "What?"
Doctor: "Stop it. Stop doing that."
"Uh, I don't understand. Should I---"
"Ok maybe I'm not making myself clear. Sometimes that happens. So I'm going to say this again, very carefully, and I need you to pay attention."
"Yes, Doctor. Go ahead."
Then he would get up and yell, "STOP ITTTTTT! JUST STOP!"
Then hand them the bill and say the session was over.
Read your iTunes agreement. I think you will find that they already have this.
Apple unofficially accepts responsibility for the AppStore apps. They don't vouch for their quality per se, but they do vouch for the fact that they won't wreck your phone.
The same can't be said for apps on an open platform.
Hackers love open platforms but users flee them because the experience is painful.
Very well said. The developers the app store is designed for are the boring, careful, professional developers who create polished, shiny, dependable apps. And that's what most users want. They want freedom from fear -- freedom to search the App Store and download whatever they find without without worrying about their level of sophistication. They want Disneyland, not a bazaar in Cairo. They want new Times Square, not old Times Square.
As a matter of pride, developers and early adopters refuse to acknowledge this factor. They pride themselves on their savoir faire and their ability to safely navigate an uncontrolled software ecosystem. The image of Apple users is carefree, self-assured, and adventuresome, and consumers can't feel that way in a place that is wild and unpredictable. They need Disneyland.
We associate the BSOD with Microsoft software. However, in the majority of cases, the bug is in someone else's code or is a hardware problem. These days it drivers, but in early Windows (pre-NT), applications could cause the system to die.
I suspect that Apple are vetting to avoid bad apps from tainting the perception of the platform. The platform is what they care about, "like Google cares about search".
If an app is buggy and fixes or new features don't turn up the end-user blames the app vendor. If the device crashes, the end-user blames the platform vendor. Those things can stick; witness how the BSOD has influenced perception of the Microsoft platform.
Avoiding that is a reasonable thing for Apple to want to do. However, I agree that the way they are doing it is probably counterproductive.
But the review process is not the part of the App Store that made it successful, nor the fact the applications are so limited and can't use APIs outside a strict list.
2. This is not something you can fix with more reviewers... it's not just a matter of time, but there no way to create an objective review system, at least if you don't limit the review process to macroscopic stuff like "the app does not work" or "there is a huge disney logo", but in big companies you can't do things like this. If you have got the review process then even a 3 pixel logo of something remotely copyrighted will stop the process.
Also, the more reviewers you need, the less qualified you get, and it requires to be very sensible to handle well the review process. I don't think this can work. Jeff FooBar will simply read all the rules and apply them without the ability to figure if it's really applicable in this particular case. So like it happened recently if there is a program to connect to your mac, and it shows an icon accordingly to the model of mac detected, and there is a 10x20 pixel mac os x default aurora background, he will stop the application.
2. The review process is almost exponential, every week you have more apps and updates to all the existing apps. Maybe Apple is hiring more reviewers; they might have to just to keep up. Having a paid review tier just means that big developers get a 1 day turn around and indy developers get the left overs.
Today my small team of developers submitted the first "toy" we released just to test how the approval process works. Let's see if we'll have some bad experience as well.
Do you see my point? To anybody outside the app development community it's going to look a little bit "self important" for developers to be using such strong language and talking of boycotts over something most folks would agree is not evil. I agree what Apple is doing is stupid, in the long term the app store is going to be polluted with crappy apps and they're approval backlog is going to be rather daunting. I think strong lobbying from the development community is in order, but it takes conscious and deliberate inhumanity for me to label someone "evil".
A company should have the right to control the user experience offered for a device that it designed and manufactured. That will mean denying a third party's right to bypass those controls.
The user has the right to do anything with the device once they've bought it.
It's beautiful, clean and comes with with Debian based distro, Maemo.
My opinions about apple were never positive, probably because I'm only 25 and did not program in the 80's. I've only saw apple as a manufacturer of shiny, well designed rich boy toys, but that is probably because I live in Brazil, where only rich people have it and they think they are 'computer people' because of it.
I was always more influenced by the open source community, and apple's record is far from shiny on that aspect.
My 2 cents.
[1]http://en.wikipedia.org/wiki/Nokia_N900
Personally I've never been an iPhone fan either purely because you can get phones with far, far better technology for the same price. iPhone wins hands down in UI right now (I still hate touchscreen-only phones though), but that really won't be an issue for long with Nokia/Samsung/SE/HTC working double time to improve their OSes.
I was at the BB Dev Con last week and their tech lead explained the approval process: "they load it, make sure it doesn't crash the phone, then sign off on it."
I made three applications (only one that was popular - WiFinder) for the AppStore. Every time I interacted with reviewers, either by e-mail or phone, I got the feeling they had no idea what they had signed up for, and had not thought out beforehand how to deliver on the promise of only having quality applications in the AppStore. Which is a shame because it's an old problem.
http://ycombinator.com/rfs5.html
http://news.ycombinator.com/item?id=950781
It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run in 12 seconds.
But it took 6 days to get through QA (while the users continued to suffer). QA's biggest complaint? I indented 4 spaces instead of the (unpublished) standard of 5 spaces.
Of all the things I have to deal with, nothing pisses me off more. Software QA is becoming more and more like TSA security at the airport: illogical, and obviously so. Last year, flagrantly unacceptable code was promoted without question while its replacement was held up on a meaningless detail.
I got the feeling from the programmer's quotes in this essay that the same thing is happening at the app store.
We programmers are a funny lot. Make us struggle for business or technical reasons and we adapt beautifully. Make us struggle for something stupid and we just get pissed off and do something else. What a pity.
If the feature was really critical and important, QA should find a way to expedite the verification, but it should never be skipped in order to ship the fix faster.
QA is important, but determining how many spaces a line of code is indented is not QA. That is a code review, which is important, but not critical. There should be automated acceptance tests, so that new releases can be shipped immediately. (It's also worth noting that stuff like indenting, naming conventions, etc. can be automatically checked at checkin time. See Perl::Critic, for example.)
If there is some feature or corner case that the users test but isn't in the acceptance test suite... well... yeah, the software is going to be unreliable. So don't do that. Write a test.
(I worked somewhere with a QA department once. They didn't like it when the programmers wrote tests, because they felt their job would be threatened. It was true, so we were asked to only write unit tests; no "integration" or "acceptance" tests. I quit a few weeks later.)
No developer should limit themselves to unit tests.
As an optional if the QA people are good then describe what else might be effected by the code (if you edited a generic component). Good QA people will run your test, work out their own variations and also check other areas.
At ThoughtWorks we work with QAs constantly. It's a great relationship. There's no such thing as "QA's bugs".
Any decision made that promotes inefficiencies to "save jobs" puts the entire company in danger.
I'm not saying you're wrong, I'm just saying there's no hard rule on this. I've had to push code many many times without any outside testing and while occasionally it's been detrimental (but fixed quick, because I didn't have to go through QA), the large majority of times has been beneficial.
A large and formal QA process can kill a product / project just a quickly as cowboy code.
No developer is good at testing their own code because deep down no developer wants to break the code they just lovingly crafted.
(In fact I just refactored this comment to fix a spelling mistake... but I published it without writing any automated tests, or running it by QA... somehow I don't think many people noticed)
I think people are responding to the suggestion that in general developers will subconsciously protect their ego by willfully ignoring flaws in their own software. That is just tremendously offensive to any real hacker, and if it were true the world of software would be a pale shadow of what it is today.
When a new bug is found (a good one, not BS indentation) then QA has a justifiable joy in finding it before it got to the customer. The developer may also be devoted to quality, but doesn't your heart sink a little when you see a new bug? Overall you both want to ship good product, but your minute-to-minute motivations are just different.
When no one is looking (the first, buggy, submission is made), they will do the minimum necessary and approve it, often quickly.
Then, when everything goes to hell, all eyes are on them. The developers submit a fix with the note "this needs to be approved ASAP to put out fires"... the QA person resents being told what to do, and suddenly feels compelled to justify his job by finding anything and everything that could possibly be considered 'wrong'. There is also the issue that things like indentation are more visibly 'wrong' than obscure bugs that only show up in production environments due to the way database replication is set up.
Now, I'm not saying all QA people are like this. I've worked with some downright awesome QA people before. But awesome QA people don't reject things for spite, and usually don't stay in QA long before moving up.
It is more like there is a problem with an important application, everybody gets the blame. The developer, QA, PM.
So everybody wants to make sure it goes well. The developer. The QA.
The QA doesn't always understand all the contraints put on him, that he has to follow. For example, if this is a fortran program, the indenting will cause it to break. So rather than second guessing every step, he follow every step of the book. So if there is another problem, he doesn't take the blame.
Or do you really mean "held up by code review" when you say "get through QA"?
Treating QA as a step after development is a mistake that causes endless suffering to users.
Indeed QA is not a step after development, but I'd argue that encouraging developers to become better at QA themselves is a more effective approach than having non-coders inspecting sources after the fact.
Value - stuff should work after it's been through them
Costs that I've seen - more stuff doesn't get done/fixed because of the delay time associated with QA - things don't get scheduled because of lack of QA bandwidth - additional specifications required in order to go through QA - programmers / PMs worry less about catching bugs because they feel it'll come back from QA
When is it better to QA something rather than just measure when it's broken? Everything we do goes through QA but I'm sure most of it is a net loss.
Anyone have a good way of knowing what to QA and what to simply monitor?
We had a backend process that connected out to a network and did some things. However, the network it connected to changed their protocol, so our backend process was broken - didn't do anything - completely non functional.
We created a fix, but had to wait for it to go through QA for ages. What's the worst that could happen? It doesn't do anything like the current version? It wasn't even a massive update. Maddening.
Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.
Again, not justifing it taking ages, just saying there's never an excuse to skip QA.
The worst case was that it maxes out the connection and burns through bandwidth. But that's something that can be monitored.
The customer would have rather had something working with the network, than something broken with the network.
In that particular circumstance, there's always an excuse to skip QA. IMHO.
No, there isn't!
Thats a good point (even though in this case it turns out not to be true).
Seems like the right answer is to back out the change.
This is the best YC quote of all time. Thx, edwin!
Apple must understand this, and they can't possibly believe they'll be allowed to maintain this sort of dictatorial control over people's primary general computing platform
Maybe our generally-accepted notions of what should succeed in the market is wrong.
Otherwise we won't see or hear of any solutions until June 2010 @ WWDC. (Apple is not involved with Macworld this year.)
They clearly understand consumers, software, infrastructure & user-experience. They missed the boat with the ipod, here's a fantastic opportunity to do something about it.
Amazon apologized; it's unlikely they'll delete books again. I trust them more.
However, I think that the essay misses a couple of points.
1. The essay rejects the notion of an "intermediary" or a "software publisher". However, it fails to appreciate the fact Apple has opened up the mobile app market to developers and eliminated far worse intermediaries (the walled gardens of carriers). This is a huge order-of-magnitude improvement.
2. A lot of developers do release badly-buggy apps out there and then end up "blaming" the Apple review process for their customers dissatusfaction. While I agree with the launch-fast-and-iterate approach, I don't think developers/companies should use that as a license to release poor-quality crashing apps. Cutting/postponing features to launch the app quickly can be a good thing, not testing the app and releasing an app with crashing bugs is not a good thing. ---
I don't expect Apple to throw out the review process, but I do hope that they improve the review process. A simple/easy improvement would be to show the latest queue ranking of apps that are waiting for review. That will go a long way towards reducing the "ongoing karma leak" that pg mentions.
Replying promptly to developer emails about app-store rejection will also help. Setting a limit of n apps for a $99 license may also help Apple cope with the incoming deluge of apps
2. I'm not sure what you're trying to say here. The review process exists so developers are already doing their best to not be rejected and Apple is rejecting anything badly-buggy. Bugs still escape that process, it's inevitable. Fixing them should be easy and quick, but it's not, and Apple is entirely to blame for that.
That said, with OS X they really became a lot more developer friendly just because they adopted a UNIX base. At this point, I'd say they're the default platform for ruby/web development. Look at all the rails job postings for small startups promising 30" Mac Pros, etc.
I'm pretty sure that it was dominant at the time. I remember reading a lot of examples that used it.
But I dont think it was purely a codewarrior issue. The overall apple OS at that time was simply terrible and 10 years behind windows (i wont even count how far behind unix they were) -- they still could not get multitasking to work right. Which meant that any pointer error causes your computer to hang. And when you are coding for a data structures class in C all of your errors are pointer errors.
So I am sure a lot of developers abandoned the mac platform around those times, but maybe many of them are coming back now.
I wish I could remember the quote well enough to search accurately for it.
http://kotaku.com/5397908/carmack-working-with-apple-is-a-ro...
And while there was a dead period due to the technically deficient underpinnings of the late Classic MacOS, before that, the Inside Macintosh days, I hear folks loved programming Apple too.
After having been deeply involved in the Mac dev community for the last 10 years, the implicit claim that Apple is a company pro developers do not love working with sounds, frankly, a little bizarre.
Our first app was built using 'unsanctioned' technology, PyObjC (before PyObjC shipped with 10.5); the app would have never seen the light of day on the iPhone, but then again, we would never have built it in PyObjC for the iPhone to begin with. Everyone we've ever met at Apple has been supportive from day one, and we owe a lot to many of those people.
We have not shipped any iPhone apps, so I can't say how I'd like that, but as a Mac app developer I love working with Apple.
Obviously without good and satisfied developers those benefits are moot. I'm certain the approval process needs to be [improved/changed/redesigned/removed], and maybe some kind of sanctioned jailbreak should exist where more advanced users can manually install third party apps, but I do believe the App Store itself is a good thing when you you look at it from a user perpective.
Apple do understand software. You cannot release Mac OS X, iLife and other jewels without understanding software. Also Mac developers jumping off the iPhone bandwagon are not jumping off the Mac plateform.
For the iPhone, Apple tried a different model that nobody really tried before.
They indeed have a broken store but the previous models on other platforms never worked. The most successful one before was for the PalmOS and it wasn't over the air.
However Apple always been an arrogant company. With their customers, their providers and their developers.
The climax of this arrogance has been reached with the iPhone eco system (certainly helped by the arrogance of the mobile phone operators).
And for many it is not sustainable.
But anyways, who really cares?
Apple can open the doors of the store overnight. It wouldn’t have been the first time they do one thing making you beleive it was the only way and then suddenly change in the opposite direction.
That’s the strength of Apple: they can change. Not only they can change but they usually know when, with what, for who and at which price.
I never realised the arrogance was a trade mark of this process though. Note: I don't mean being evil by being arrogant.
I think he just left out a word: marketing. They know how to build it, for sure. Paul's point is that they're marketing it like it is music.
None of this is new, the only difference is that there's now a release bottleneck that requires Apple's approval, and there's a lot of developers new to the platform.
The thing is, this is part of Apple's culture for a reason. Steve is an obsessive control-freak when it comes to a great user experience, and third party developers are seen as a threat to that. Microsoft has always been a great company to deal with as a third-party developer - they value their ecosystem, put effort into free documentation and solid IDEs, and rely on outside developers for key applications. The trouble with this comparative openness is that you end up with 800 pieces of software written by different companies fighting it out on your desktop, leading to crashes and inconsistent UIs all over the place.
I think Apple is in danger of screwing up a great opportunity with the app store, but this way of operating is in their DNA and it won't be easy to change. Despite what the geek consensus might be, the record shows they've made a lot of money in the past whilst ignoring third-party developers.
And that's a bad thing because? Who has the mainstream OS now with over 87% market-share? Even popular cross-platform applications that were first available for Macs (like Adobe Photoshop) are now more optimized for Windows.
Microsoft has always been more open ... you can install Windows on any hardware you want as long as it's compatible (and most hardware is, with the notable exception of ARM-processors).
The developer tools where a lot more competitive because Microsoft allowed competition from the likes of Borland. And the Windows API was free to use (as opposed to OS/2 for instance). And for end-users ... Microsoft has always been committed to backwards compatibility (at least for popular applications).
Microsoft can be called "evil" yes, because of their aggressive tactics regarding competition. But imagine what would Apple do in the same position ... and it's kind of ironic that many developers choosing openness went to Apple for that.
Apple makes money, yes, but they were on the edge of bankruptcy ... they should've learned a valuable lesson then (besides keeping Steve Jobs as the CEO).
Sorry, I had to laugh.
Part of the blame for Itanium losing the 64-bit bandwagon could be pointed to Microsoft, for not having Windows ready for it when it became available. Or for delaying the launch - it's silly to launch a processor without an OS to run it on.
Having Windows support for your hardware is paramount to any desktop computer company since the early 90's (with the notable exception of Apple). Alpha, MIPS and PowerPC (as in PReP) desktop systems are not dead because x86 systems were a better price/performance choice: they are dead because Microsoft pulled the plug on NT for them (and Linux was not ready to take its place at that time). That's also why all our computers are remarkably alike from the inside. It's not that Microsoft is open - it's that they have computer makers cornered.
Today I can get a non x86 computer and expect all my userland to work (with the possible exception of Flash, Skype and parts of Eclipse). I could not do that in the 90s.
The Itanium is not an expensive server chip because Intel cannot build an Atom-like processor with the Itanium ISA (heck - it must be easier than do it with the x86 ISA). It's an expensive server chip because it won't run Windows 7 and Office.
I see very little competition in the development tools in the Microsoft space these days. Tool makers know better - if they make something that competes with Visual Studio, Microsoft will come after them in the next release cycle and it is not worth the pain to fight them. That's why every non-Microsoft development tool around is built for a niche. Or is free, a case where Microsoft will not be able to go after you. That could be a reason for the free language explosion we are seeing.
And thanks. The Psystar imbroglio is a statement of how evil Apple can be about competition these days.
It even seems that after stopping attracting the best and brightest, they started attracting former Microsoft minions...
Steve seems to think that the benefits of closed systems (standardised UI, fewer crashes) outweigh the costs (more expensive, less software). I don't have to agree to recognize that he's making a rational trade-off.
Makes sense. I think it is not by chance that OSX is the least customizable OS around (and that's why my mac runs linux).
It is my understanding that apps can also be installed directly from third party websites... If so, is there a way to create an app for the App Store that is a shell to a website where a conglomerate of listings can be offered? It seems this would give the value of having everything fairly easy to find (one extra click) and yet get out from the management of the App Store for all but the original shell app...
This is not true, and that's the essence of the problem.
You can install software that you've written yourself on your own phone. And there's some sort of deal that lets you give your software to beta testers and let them install it. A year or so ago some clever fellow tried to use this beta loophole as a way of selling an app that was banned from the App Store. I believe they threw the book at him and he had to stop. I haven't heard of that happening again.
You can distribute apps for jailbroken phones, but that is not really a solution.
I agree in spirit the system is screwed - but Apple do have a hell of a lot of sway. They have the leading product and the huge customer base (and the cool factor). To a point they can dictate things (and I agree this is bad and we should stop them)
Much of my free time in highschool was spent creating games on it. It's extremely easy to develop for (it uses a variant of BASIC), and the menu system is designed to minimize keystrokes, which means you can bang out your code very quickly.
Of course, the platform is very dated: 6 MHz CPU, and a 96×64 monochrome LCD screen! I'd love to see something in the same format, built with modern technology. Maybe the default language could be Python.
That's a mobile experience that I'd get excited for.
I spent every calculus class working on various things. My proudest accomplishment was a blackjack game. I implemented drawing routines for every card type, which was really painful given the graphics primitives you had available. So much Line(..) and PxOn(..).
Distribution mechanism was hooking up that cable to your classmates' TI-XX. Maybe iPhone devs should try that.
It's nowhere near as powerful as a PDA, but it has a great keyboard (for math, at least) and runs off AAs.
Now, this doesn't mean that developers won't want a developer friendly phone, or that Apple is hurting their reputation with developers. I'm certain it has been frustrating to deal with the whole process. However, if 3rd party software isn't essential for the iPhone as a platform, then developer satisfaction moves down a bit in terms of importance in Apple's eyes.
Now, it's clear that games are major for the app store. Games are also a special class of software application that benefits disproportionately from having access to the hardware at a low level. They also have properties more similar to music and movies (incidentally, things the iTunes store is good at selling). Except for the simplest games, they require a lot of up-front design work and investment. It's rare that a released game goes through a ton of rapid iterations to "get it right". Games may still have bugs after release, but in general the functionality they are going to have is there on day one. They also ship with the final sound effects, music, artwork, etc... Games are also probably very unlikely to "duplicate existing functinoality" or any of the other cases where "normal" apps hit barriers. Perhaps Apple has (intentionally or unintentionally) created an environment optimized for game approval?
I'm certainly not defending the app store process, but I just wonder if the software development community has a disproportionate view of its importance to the iPhone as a whole.
The OS bundled ones are the ones people use the most. Across the board.
If I had to guess, I'd say third party apps are just as often or more used on iPhone than on, say, Windows and Mac OS X. Simply because, on iPhone, a lot of web apps out there are used via a special-purpose iPhone app rather than the web interface.
I don't think there are any killer mobile apps yet. Maybe for some it's FourSquare or FB, but I can't think of one app I'd miss that's not built in.
If you polled a random user of, what are the chances you would find an app that they will get very pissed off at it's disappearance?
What are the chances they will actually skip platforms?
On Windows or OSX, I think the answer is high. On iphone, maybe not.
It is still a luxury for most people - "oh cool look at this app," but it still comes down to those that can afford an iPhone. I can imagine there are many family squabbles involving parents that bought their kid an iPhone that racked up an App Store bill the parents didn't originally intend.
iPhone is not a business phone overall - and therefore doesn't have "critical apps".
I really doubt this is true given the lack of any killer mobile apps. I don't personally consider any of desktop apps in the list I gave 'killer', but fairly sure they've sold lots of computers.
When I hear someone say "I wish I had an iPhone right now", it's usually because they're either (i) lost, or looking for something, and want access to Google Maps, or (ii) in the throes of gadget envy. The App Store addresses (ii), but not with any single app -- it's just the idea that there are thousands of fun toys that only iPhone users get to play with.
So there are a couple of killer features, but nothing that can't be replicated on other phones. Not necessarily as well, but that's not the point: without exclusivity, the iPhone will not get the same kind of dominance Windows has.
Part of it may be a byproduct of the way the console games distributed on ROMs or disks. That may change, for consoles nowadays have network connection and can get updates anytime. There's another part, however, that some type of games fits this "done is done" philosophy. Like novels or movies, which you don't expect them to be improved over time.
Well, I don't defend the app store process either, and I believe majority of software should be developed in the iterative process. It's just interesting that games may be a marginal area that has some peculiar properties.
Apple wants iPhone apps to "just work" They don't want a plethora of buggy, half-baked, inconsistent apps in their store, because this would diminish the brand. It would be like a typical Linux distribution where half the apps implement their own peculiar UI conventions, crash often, or just don't work at all.
So it is like developing a game. You get one release, one chance, to get it right. It needs to work. Maybe a lot of app developers don't get this. There are published standards about conventions, icons, behavior, etc. The app is expected to be FINISHED and WORKING before you submit it to the store. Don't count on deploying 27 follow up patches and updates to customers -- imagine the chaos if every iPhone app needed updates multiple times. Users (most of whom are not hackers) would, after a while, just give up and abandon the platform.
So, when an app is submitted, it is reviewed, and if it's found to be buggy, or it doesn't work, or it works in an unconventional way, then they don't want it. And they're not in a particular hurry to waste more time on you when you didn't follow the instructions the first time.
I don't know, I'm just speculating. But this seems plausible to me.
I think this is a good "oh yeah, this is why we do it" argument, but is probably more of a by-product of the review process and less of Apple's original incentive.
A lot of the technical decisions that are made are motivated by business and profit. Not to say that this is a negative thing - Apple is a corporation after all. There are plenty of things I've seen done that are dumb as hell at my employer (at a technical level) but are motivated by external reasons that seem implausible or illogical because the guy writing code is too far removed from the information and the decision.
however, speaking as a guy who has went through the process for 8+ apps so far, that's not the pain point.
It's more about repeatedly encountering dumbass reasons for rejections, and dumbass long delays to get feedback on things that should take about 1 minute, not 2-4 weeks to get feedback on. It's about getting rejected for 1 thing, and then they don't bother to finish reviewing the app and discover the other 2 things that they know they would reject it on during the next submission, so you don't find those out until 2-4 weeks later, and so on, ad nauseum. It's about rejecting for inane reasons (that they can "fix", if they wanted to, and had a brain, by running a small piece of software on, shotgun-style) like 'this config value over here doesn't match this value over there, so please make those the same', or even worse, vague mysteriously-worded rejections, or rejections that contain explicit instructions for "fixing" the issue and then you follow them, resubmit and they reject again.
Dumbasses. I keep coming back to that word over and over again when dealing with their review process/people. We're talking about a company with supposedly billions of dollars in cash in the bank and until a few months ago or so reportedly had what 50 full-time reviewers on staff? (Do the math on what it would cost to even triple that staff and you'll see it's a tiny drop in the bucket compared to the profits that keep rolling in.)
Device? Love it.
OS? Love it.
Design sense? Love it.
App Store submission/review process? Dumbasses.
The year that iPhone existed without the App Store, no smartphone competitors came close to replicating it's core functionality and user experience. I don't think that's quite true anymore, and so I think that the App Store is one of the iPhone's key advantages. Specifically, the iPhone didn't need the App Store to differentiate itself from RIM and WinMo in 2007, but I think it absolutely needs the App Store to differentiate itself from the Pre and Android in 2009.
I don't think there is one killer 3rd-party app on the phone that everyone needs to have, but there could very well be many third party apps that smaller niches need to have. For me personally, MLB At-Bat (live streaming of baseball games) and the Kindle reader are actually the two biggest factors keeping me from switching to Droid. Those applications could easily be ported to Android, but haven't been yet, and in both cases a third party holds the distribution rights for the content so it's not like me or another hacker could replicate those apps easily.
I wouldn't believe that for a minute. The App Store would have been part of the iPhone product plan from day 1. It's too big, too complex, too strategic, and (yes) too well-executed to be a panicked response to developers' demands.
That's how Apple under Jobs has always done things: major features are not "supported" or "planned" or "offered" or "part of the company's philosophy"... at least, not until they appear out of nowhere one day.
“I don’t want people to think of this as a computer,” he said. “I think of it as reinventing the phone.”
"We define everything that is on the phone,” he said. “You don’t want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesn’t work anymore. These are more like iPods than they are like computers.”
The iPhone, he insisted, would not look like the rest of the wireless industry.
“These are devices that need to work, and you can’t do that if you load any software on them,” he said. “That doesn’t mean there’s not going to be software to buy that you can load on them coming from us. It doesn’t mean we have to write it all, but it means it has to be more of a controlled environment.”
But the App Store was announced to the public only seven months after that, in June of 2008.
If they did all that work in seven months, my resume will be on someone's desk at Apple by Monday. Seriously. I don't want to compete with any large companies that can move that fast. They win.
No, the only reasonable conclusion is that you can't take Jobs at his word when he appears to rule something out.
Edit: And the question isn't really were they going to have an app store or not - they very well could have been thinking along those lines but reserving it only for software they themselves were going to create or with select partners - the question is whether they were going to open it up to general developers which I think they did not want to do.
Any app that makes someone get an iPhone instead of something else is a "killer app" as far as Apple is concerned, even if it only sold a total of 27 copies and lost the developer a lot of money. So even if the iPhone doesn't have any one killer app, the sheer diversity of apps means there is probably a killer app out there for most people, and that is vital for Apple.
All the ads I've seen lately for the iPhone are of the "there's an app for that" variety. So Apple themselves seem to think that the apps are a critical factor.
That being said, the iPhone sold very well before there were any apps at all.
I agree with others - the app store is not that important. It's a fun thing. I'm not convinced it'll even be around/relevant in 5 years.
Developer relations are central to Apple as a whole. Apples needs iPhone developers, desktop developers, web developers and developers for whatever they do after the iPhone. If Apple creates hostile feelings in the developer community with its App Store behavior, Apple is going to have ongoing problems regardless of whether it needs third party developers at the moment.