Live data from Hacker News

Apple's Mistake

paulgraham.com

211–220 of 285 posts

Re: Apple's Mistake

#211

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…

Does Apple examine your source code?! I thought iPhone devs kept the source to themselves.

No, just the symbol table in the binaries. You can easily do it yourself with the 'nm' command. It seems that they are using a tool that matches the 'nm' output with a list of private APIs since about a month or so, meaning that a lot of updates suddenly get rejected like this. What really annoys me as a developer though, is that they should be able to automate this check and give feedback instantly. (It's not like they will give feedback on more than one 'problem' anyway.) Instead you'll still have to sit out the 2 week waiting period.

Re: Apple's Mistake

#212
I cross-post this from the other thread I started since I noticed the Apple heat is in this one, if you want to learn the background about my app, check this thread: http://news.ycombinator.com/item?id=951360

Below is what I've learned after 2 months of AppStore dev.

Here are a few dirty tricks & ideas that I hope will make life in AppStore purgatory easier:

Use the 'Easter Egg' field to plead directly to the reviewer. It's a free-text field that every reviewer will read and a little social engineering will work wonders.

If the app name is important to you, reserve it by submitting a dummy app without binary. You'll need dummy 512x512 and 480x320 artwork in order to be able to fill out the form.

Phone contacts at Apple are pure gold. I consistently got on the line with the same reviewer. Depending on their mood reviewers can expedite things. But it's still pretty random.

Set your app price low ($0.99) while it is in the review queue & jack it up immediately on release date. I got an app rejected because the reviewer did not like the price I set.

It pays not to be a bottom-feeder. Maximize revenue, not units of sales. Often a slightly higher price will give you more revenue. There's more than the $0.99 price-point. At a higher price point you can also afford to pay higher CPM/CPC for initial customer acquisition.

Count on doing your own marketing. The time when you could solely rely on rankings to boost your sales is over. The AppStore UI is so broken right now that you have to assume that your customers will not find your app without some effort of your own.

Expect long approval times. I've started thinking in development/update cycles of at least one month. Agile is not the mindset at Apple. Work on new apps while your other apps are in the queue. I wish Apple would crowdsource the approval process or look into setting up community-managed 'repositories' like Linux.

App Complexity is a good predictor of approval time. This is a big problem because it does not reward taking on the risks of building better apps. It took me 2 months to build up the confidence to start a more complex project.

Private API calls are an absolute no-no: even if you were approved before, your next update will be rejected because Apple started using automated tools to inspect your code.

If you give unlimited access to the internet through a UIWebView, your app will be pulled unless it has a 17+ rating.

There's no (easy) way to measure where your app sales come from. This makes traditional SEM/SEO difficult. You have no conversion numbers so your marketing funnel is broken.

Don't mention Apple products in your description. Don't use images of Apple products. Don't mention real-life persons in your description, I got an app rejected for that last one.

Don't count on being able to schedule a release date. Once you do get the approval mail, go into iTunes Connect & set your release date to $NOW. Remember, this can work both ways: I got surprised by an early release before my marketing materials were ready.

Yes, you will be pushed back to the queue upon rejection, even if you have the reviewer on the line and beg him to make an exception.

In all fairness, not all is bad. Apple seems to have started picking up speed lately. My experience with App approvals has been that it got faster in the last 2 weeks, at the same time when the AppStore itself went in disarray (wonky rankings, wrong release dates, ...). However, take care and remember "Correlation, Causation et Al.". Also, once I was in contact with Apple over the phone they were very courteous and professional in resolving issues. Slow & polite.

Re: Apple's Mistake

#213
post #211

Earlier quoted context omitted.

Does Apple examine your source code?! I thought iPhone devs kept the source to themselves.

No, just the symbol table in the binaries. You can easily do it yourself with the 'nm' command. It seems that they are using a tool that matches the 'nm' output with a list of private APIs since about a month or so, meaning that a lot of updates suddenly get rejected like this. What really annoys me as a developer though, is that they should be able to automate this check and give feedback instantly. (It's not like t…

Seriously if they are so hung up on undocumented API calls, they should just implement that check as part of the binary upload process. Run the binary through an automated flagging system. This will not only benefit developers but also cut their review time plus reduce the number of update submission indirectly.

Re: Apple's Mistake

#214
I'm sure part of the reason Apple isn't as keen to rapidly iterate its software is because it wants to keep its image of quality software up.

There are also some benefits to having a closed app store. 1) No viruses 2) Easy platform to collect payments 3) What else?

Re: Apple's Mistake

#215

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…

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

Re: Apple's Mistake

#216
post #72

Laptops displaced desktops?! You are deluded. We develop on 8GB i7s with dual 24" screens. We have one at home and one at work, Remote Desktop-ing from each other. Gigabit ethernet and optical fiber internet. No molasses wifi here. We work FAST, we work HARD. But we use Windows 7 too, so we're not limited to Apple's crappy hardware either...

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?

Not that I care much, but what makes you think my comment is untrue?!

Re: Apple's Mistake

#217

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.

Apple employees have the advantage of being paid by Apple to work that way.

Re: Apple's Mistake

#218
post #80

That mobile platform has already arrived. It's called Windows Mobile. I was surprised too: my wife has a 3GS and I was planning to get one for myself too. Instead I got a HTC Diamond2 which I plan to upgrade to a HTC HD2. I'm a developer, not a essay-writing millionaire. I like platforms that are Powerful, flexible and CUSTOMIZABLE to my taste. I like pretty too, but form has to follow function, not the other way aro…

But does your wife want a hackable phone? Does she really care? Does she want to have to deal with it when she downloads an app that sounds cool and it ends up installing spyware on her machine and drains her battery and drops her phonecalls? Or would she maybe rather give up some hackable freedom for ease-of-use and a promise of a protected experience?

No she doesn't. She's perfectly happy with the iPhone. Even if she envies the functionality on my HTC sometimes.

But the discussion here were HACKER phones, not consumer phones.

Re: Apple's Mistake

#219
Yep, we had another rejection yesterday for a "pre-existing condition."

Our latest release of Gaia GPS was just a handful of bug fixes - no feature changes - and Apple rejected it on the grounds that our map screen didn't warn the user they were offline.

They also rejected the new version of our Lite app for a totally different reason - because we used a "private" API - actually just a function restricted to Mac programming called dateWithString.The non-lite version builds from the same code, so it's also annoying that they just pick one random thing to reject you for. They didn't mention the "private" API call for our non-free app at all.

Re: Apple's Mistake

#220
post #212

I cross-post this from the other thread I started since I noticed the Apple heat is in this one, if you want to learn the background about my app, check this thread: http://news.ycombinator.com/item?id=951360 Below is what I've learned after 2 months of AppStore dev. Here are a few dirty tricks & ideas that I hope will make life in AppStore purgatory easier: Use the 'Easter Egg' field to plead directly to the reviewe…

You list of advice is good. It's that it needs to exist to put software on one of the most popular devices of the decade that's absurd.

In the 80's you could travel pretty freely as a western visitor in communist eastern Europe if had a similar list, telling you who to nudge where, what gifts to bring for cheap bribes (IIRC I heard that a good ball point pen got you far in some places) and so on. Now, the ultimate solution isn't a better list, I think was PGs point.

Post reply on HN