Live data from Hacker News

Apple's Mistake

paulgraham.com

101–110 of 285 posts

Re: Apple's Mistake

#101
I totally agree with the article. However I wonder what prompted PG to write it. Did one of their startups' apps get rejected recently?

Re: Apple's Mistake

#102

Paul Graham should pull a Kevin Smith and put his writings into a book. I would buy it. If it already exists, someone link me!

Really? http://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp... From 2004, but comprised mostly of essays that are on his site.

Jackpot!

Re: Apple's Mistake

#103
post #10

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…

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.

Re: Apple's Mistake

#104

I have now two published apps in the App Store. Both business apps - one in finance and the other in business. The biggest change they have made that took me off their platform was their recent policy to not show updated applications along with new releases. Let me explain. For the longest time, if you looked under released applications you could see applications that were recently updated. This was a great incentive…

This was a great incentive for developers of existing applications to keep updating their applications and getting it easily noticed by users.

It was also a great incentive for developers to game the system and swamp the reviewers by submitting trivial updates every week to keep their apps at the top of the list. Tragedy of the commons.

Re: Apple's Mistake

#105
post #92
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…

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 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.

Re: Apple's Mistake

#106
post #25
post #6

Earlier quoted context omitted.

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.

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

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.

Re: Apple's Mistake

#107

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

Oh yeah, the BASIC on those TI calcs!

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.

Re: Apple's Mistake

#108

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

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.

Re: Apple's Mistake

#109
post #94
post #71

Earlier quoted context omitted.

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…

I don't agree. On the desktop there are 'killer apps' like Photoshop, Excel, Quicken, Final Cut, etc. 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.

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.

Re: Apple's Mistake

#110
As far as a handheld development machine, the Pandora comes to mind: http://en.wikipedia.org/wiki/Pandora_(console)

Looks pretty powerful, roughly the size of a Nintendo DS. Of course, it won't replace a laptop... the keyboard size alone.

But if I could sync code between the Pandora and my laptop and compile stuff on-the-go. The Pandora could function like notepad for writers... but for programmers.

Its usefulness in developing for windows applications would be very limited, however.

Post reply on HN