Live data from Hacker News

Apple's Mistake

paulgraham.com

181–190 of 285 posts

Re: Apple's Mistake

#181
I don't think we'll see a "proper" handheld developing environment until AR specs, Accelerando-style, become linked with virtual-keyboard interfaces in a big way. (I'm talking the sort of thing that detects the position of your hands and fingers at all times, so you can type on a keyboard that exists only in your glasses. Force-feedback gloves might also be important, for that clicky-keyboard feeling.)

Re: Apple's Mistake

#182
post #172

Earlier quoted context omitted.

Although I don't think your comment is true, I do have a question for PG: Did you buy the 27" iMac just to use as a monitor, or for the computer part as well?

I bought it as a computer. It's my new, separate machine for using the Internet, as described here: http://www.paulgraham.com/distraction.html

The moment Apple decides to make a model with a non-glaring screen, I'll buy one too.

Re: Apple's Mistake

#183
post #33

Earlier quoted context omitted.

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 fi…

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 a…

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.

Re: Apple's Mistake

#184
post #178
post #61

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…

Thank you, I just got an iPhone and I have found zero apps worth downloading. Take this 35 list of great apps http://www.techcrunch.com/2009/08/15/the-35-best-iphone-apps... and find something useful or fun.

Gosh, I had no idea little quality software was on offer until now. I can only see one or two useful apps in there.

Re: Apple's Mistake

#185
post #46
post #29

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.

Yeah Cocoa dev was never took off if only b/c Macs used to be much more niche than they are today.

[deleted]

Re: Apple's Mistake

#186

Earlier quoted context omitted.

They don't? I don't know about how you connect to the internet, but my ISPs owns the networks I tend to connect to.

> They don't? I don't think you correctly read my post:) No worries

>Well most windows machines do have access to a network controlled by someone else.

Too right, I inserted a subliminal "not" after the do.

Apologies!

Re: Apple's Mistake

#187

Talk about it. I just got a rejection today for a major bugfix on my last update. The only change in the update is to use utf-8 encoding---one tiny change on one line of code. After 2 weeks, they tell me they can't approve the update because I'm using undocumented APIs in a couple places. Sure, OK, looks like I was using some methods that went from deprecated to undocumented... but that's exactly what's in the store…

I think it's worth pointing out that even Apple's own developers don't get the luxury of being able to push out bug fixes whenever they want. Point releases of the iPhone OS are often months apart, so good testing is not optional for them.

Re: Apple's Mistake

#188
post #92

Earlier quoted context omitted.

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 ne…

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…

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.

Re: Apple's Mistake

#189

Talk about it. I just got a rejection today for a major bugfix on my last update. The only change in the update is to use utf-8 encoding---one tiny change on one line of code. After 2 weeks, they tell me they can't approve the update because I'm using undocumented APIs in a couple places. Sure, OK, looks like I was using some methods that went from deprecated to undocumented... but that's exactly what's in the store…

Same thing here. We just got an update rejected for a line of code that calls an undocumented API within a function that was no where called in the program, dead code and they rejected the update that had an important bug fix that we emailed them about for an expedited review.

The expedited review request was accepted but in the end took 14 days to come back and got rejected for a piece of code that was never ran and has been there since day 1.

Talk about frustration, hell yeah.

But as everyone does, after getting over the anger and back to reality and business sense, what else CAN I do but only to resubmit since there lies a never seen before first of it kinds, an easy software distribution and payment system that many other platforms did not provide to small independent developers a year ago.

It's not about just supporting one SINGLE platform, that has never been the case. Just like making web apps run nicely in IE, Safari, Firefox, etc or even Windows, MacOS, Linux. As a developer, what matter is that I support the platform that has massive adoption/users. I will not drop iPhone and go Android, or any other platform. The only decision I will make is if there's enough users on the platform that I do care about to invest and develop for that platform. One day Android might be there and I see the possibility of developing for both Android and the iPhone.

Re: Apple's Mistake

#190
btw, Android would win in long run. This process already begins with Motorola's Droid.

Apple very well monetized iPhone's wow!-factor, but now it is a mainstream thing.

Let's see what their tablet would be.

Post reply on HN