The Unofficial Apple Weblog (TUAW)

We're a pretty AIM-based blog around these parts. The fact that Weblogs, Inc. is owned by AOL may or may not play a role in that. Regardless, we TUAWians spend a lot of time in AIM chat rooms. The App Store's lack of AOL chat room support has been a real burden when we're out on the road with iPhones.

I was delighted when a recent tweet put me in contact with Björn Teichmann, author of the iPhone IRC application Rooms [iTunes link]. Rooms, claimed Teichmann, could bring AOL chat rooms to our iPhones.

Teichmann sent over a promo code for his app, which normally retails for $1.99, and spent a few hours getting me up to speed on AOL chat rooms using his software. Let me explain: It's not that setting things up ended up being difficult to accomplish, but rather there weren't a lot of clear and available instructions for doing so. What Teichmann worked out over those hours was a somewhat reliable way to access AOL chat rooms via IRC.

Read on to learn more about his solution...

Read more →

When Joris Kluivers (@kluivers on Twitter) set out to write his Lyrics app for iPhone, he never intended to personally take on Apple, Sony, and Gracenote. Kluivers, a student at the Vrije Universiteit in Amsterdam, was just trying to get his foot in the App Store door, not go toe-to-toe with three media behemoths. The story of how he ended up navigating through the corporate bulwarks to eventually successfully publish his latest release, Lyrics 2 (iTunes Link), with the blessings of all three companies, no less, makes quite the App Store saga.

The initial version of Lyrics was simple. Kluivers collaborated with Moop.me, a programming cooperative, to build his application. Published this past May, Lyrics was the first application on the App Store to allow users to find and display song lyrics. Several other similar applications followed in the weeks after.

Kluivers built the application around the LyricsWiki database. Featuring over 700,000 songs, the wiki provided easy access to a much-desired resource. It was exactly that access to a vast library of songs that caused the first of Kluiver's corporate challenges. Apple insisted on censoring his lyrics.

Read on to learn more about what happened...

Read more →

Dear Aunt TUAW,

I'm from the Philippines and I would just like to ask for your help. I don't know if the news had reached you guys but there had been some massive flood lately in our country brought about by super typhoons storming over our land. Anyway, I own an iPhone and thank God I brought it with me when the flash flood came which sadly destroyed my PC and laptop. Now I have a new desktop which leads me to my problem. I'm afraid to install iTunes in it because if ever I'd sync my phone with the new desktop, I'm pretty sure all my iPod files will be gone. Are there any work around for it (so that I can still save my files on my phone)? Will jailbreaking help (as a last resort)?

Thanks and more power! =)

Best regards,

Rand B.

Read on for Auntie's answer...

Read more →

Ever since I installed Snow Leopard, I've been dealing with a particularly annoying bug. Terminal keeps forgetting my shell preferences.

I generally prefer to use tcsh rather than bash. This is mostly because I'm a technological dinosaur. I also have a lot invested into my ancient and extensive .cshrc that has taken years to grow and develop.

Normally, I set the default shell inside the Terminal app preferences. But there's a problem. Snow Leopard keeps losing my preferences for reasons I do not begin to understand. With this Snow Leopard bug, I had to find another approach for choosing my shell. Terminal preferences were no longer going to work for me.

There are actually two very good ways to handle this problem.

First, there's chsh, as pointed out by Richard Buckle and Brian "Shmit" this morning. A command line utility, chsh edits the OS X user database, allowing you to change a user's default shell. chsh is built into OS X, and you can pull up a man page to read details about its use. Supply the shell you want to use, authenticate, and you're set. There is, however, an easier solution.

It's System Preferences. As Bill Bumgarner and Jordan Breeding reminded me today, you can access advanced user settings by right-clicking (or Ctrl-clicking) a user name in the Accounts settings; then choose Advanced Options. (Please note that you must first unlock the settings before this trick becomes available.)

When selected, an Advanced Options screen appears. You can set the new login shell in this screen. A simple pop-up list offers easy access to all installed shells. Select the one you want to use and, once selected, click OK to dismiss the screen and return to the Accounts settings pane.

This solution works a lot better than the bash .profile approach I had been using for a few weeks. Running tcsh through the .profile initialization file had caused an extra layer of interaction each time I wanted to close a terminal window. The application warned me that I was about to kill a running process (i.e. my tcsh subprocess). Changing my default shell meant I could create and close windows on demand without that extra dialog, a welcome respite.

In conclusion, while I'm not sure why Terminal keeps losing its preferences, I'm pleased that I at least learned a way to bypass the shell issue. Hopefully, Apple will get this bug fixed soon.

It appears that the Dev Center at Apple just updated its documentation set today. If you're using Xcode 3.2 and you want to update your documentation, you might be looking in the wrong place.

Before 3.2, you used to update your documentation in the Developer Documentation window (Help > Developer Documentation, or Command-Option-?). Now you'll find your documentation sets in the Xcode Preferences window (Xcode > Preferences... or Command-, and then choose the Documentation tab). Also, if checked, Xcode will automatically update your documentation when you launch it.

This Documentation panel offers subscription options for installing a documentation set (such as, for example, Mac OS X Legacy Library or iPhone OS 2.2 Library) as well as a handy Check and Install Now button that lets you request the latest updates. Use this to keep on top of the latest documentation updates.

Thanks, Scott Lawrence and @zadr

The refreshed Mac minis predicted yesterday by John Gruber of Daring Fireball, did indeed debut this morning and with a modest refresh. According to Business Week, the new entry-level mini (still at $599) offers the 2.26 GHz chip that used to be an optional upgrade. The $799 upgrade offers a 2.53 GHz performance boost.

I bought my latest mini this past Spring. Introduced last March at the same $599/$799 starting prices, those models have offered excellent performance, a 5th USB Port (I mention this as a confirmed and unrepentant USBaholic), and built in dual monitor support. (You do have to buy a second, mini Display cable to use that second monitor. I got mine from an Apple Store for about 30 bucks.)

At that time, I stuck with the 2.0GHz processor and opted for the 4GB RAM upgrade and larger (320GB) disk drive. And, let me tell you, those choices (for which I thank all the people at Twitter who offered advice) were excellent. I haven't missed the top processor speed (there was a 2.26GHz option), the extra RAM was awesome, and I didn't have to crack the case to upgrade to a better disk. I recommend you do the same today: cheapest processor (now the 2.26 GHz chip), 4GB RAM, and the larger (500 GB) disk option. If you're in the mood for extra storage yumminess, consider the dual disk server configuration: an entire Terabyte of disk in a single sweet mini.

You can read more about this upgrade at Apple's refreshed Mini features page. And yes, the store is still down at the time this post went live. Maybe someone forgot to feed the hamsters.

Wow. This has been an especially long wait for the Apple Store to return. So here's TUAW's top reasons this is taking so long.

Reason #5 (via @serpicolugnut at Twitter, updated via TUAW reader Zaph):The App Store reviewers are "reviewing" the new store. The current average wait is 14 days.

Reason #4: They might be done with their Time Machine backup by now...

Reason #3: Man, WebObjects is outdated technology...

Reason #2 (Courtesy of @verso via Twitter): Still waiting for the iPhone backups to finish...

And our top reason?...

Read more →

Raindrops on roses and whiskers on kittens
Mac mini refreshes
And warm woolen mittens
Brown paper packages from Fedex on wing
These are a few of my favorite things

Cream colored ponies and crisp Apple strudels
Doorbells and sleigh bells and iMacs with noodles
MacBooks and Pros, Apple logos that sing
These are a few of my favorite things

When the store goes down
When the anticipation builds
When I'm waiting in iTunes
I simply remember my favorite things
And what I will buy... real soon!

iPhone developer Dan B. wanted to know if Apple would reject his application based on the name he wanted to use for his app.

So he did what you'd expect a sane developer to do. He wrote Apple. He used one of his technical support incidents to speak with the Apple Developer Technical Support teams and waited for them to reply.

They were quite prompt in answering, redirecting his question to the iPhone App Review Team.

Thank you for contacting Apple Developer Technical Support. We provide support for code-level questions on hardware & software development, and are unable to help you with your app naming question.

Please contact the iPhone App Review Team for assistance. You can contact them directly at [address redacted].

While you were initially charged a technical support incident for this request, we have assigned a replacement incident back to your account.

I hope this information is helpful to you.

So Dan contacted the App Review team. And they wrote back too.

Thank you for contacting the iPhone Developer Program. This email address is for inquiries regarding status of application submissions.

Apple is not able to provide pre-approval to developers for proposed application submissions.

We ask that you please review the Program License Agreement details against the specific application you wish to develop and submit any applications for App Store consideration in line with the application submission processes for the program.

If your application does in fact get rejected by the app review team, then we will notify you on what appropriate corrections/changes should be made.

So what's a developer to do? It seems like the only way to vet an application (let alone an application name) is to submit it and see whether Apple rejects it or not. If the name is used in the application art, you might have to redesign your screens. If the application idea is not okay, you might end up throwing away all your development costs because Apple would not give a preapproval before starting serious development.

Dan's problem reflects a wider problem with Apple's App Store black box. Developers should be able to pay for support incidents for exactly this kind of situation. It appears that Apple does offer this high level of consultation to partners and other companies that they work with (even to the point of having Phil Schiller call Google directly to discuss the progress for the Google Voice app review). Shouldn't they offer a similar kind of service to smaller developers?

Have you been able to get these kinds of answers out of Apple? If so, how did you approach the matter? Let us know in the comments...

Big news coming down the pike today for App Store developers. Apple has finally relented on a sticking point in the developer agreement, allowing in-app purchases for free applications. Finally, developers can distribute a free trial version of their applications, unlocking features from directly within the app as users request them (and pay for them). Until now, developers had to deliver two applications, with two unique identities, and no simple way to share data from the trial to the full version. (Yes, you could have used servers and shared keychains, but that's burdensome and kind of pointless.)

What this news means is that developers can unify into a single application. One project to maintain and support, one place to consolidate reviews, one application sandbox for a single set of application data. Earlier today, Mike S. mentioned Gas Cubby and Gas Cubby Lite -- now there could be only one version of the app, with an 'upsell' inside to go from the light to full feature set.

Expect to see these free-to-paid apps hit the store within the next few weeks. Apple will likely be deluged with new apps to review based on this news. Visit the App Store Resource Center for more details and check your e-mail account for the developer news that went out to all iPhone devs today.

Q&A: Readers ask: "How will this affect the no reviews situation for free apps." Good question. Apple is going to need to sort that out. Since in-app purchases are registered to an iTunes account and associated with an application, it shouldn't take much work to limit reviews to those who have purchased something in a free app. We'll have to watch for this to happen because as things stand now, if you download an app, you get to rate it and developers know that free apps are thoughtless review magnets.

"How will you deliver binaries?" All the functionality must already be built into the app. StoreKit allows you to unlock those features when users pay a fee. You can download data or extend a web based service but you can't download additional executable binary components.

"Will I have to buy this twice for myself and other members of my family?" No, not if you both sync to the same iTunes account. It works the same as with applications. One app that has bought an upgrade extends to all apps for that same account. Each time your app launches, developers will check with App Store and restore any purchases that have already been made. So if you buy your upgrade on an iPhone, that upgrade will propagate to your iPod touch when it checks in.

"Will this help in anti-piracy measures?" Definitely. StoreKit allows developers to validate receipts, ensuring that unlock codes are only sent to paying customers. Add a hash-check algorithm for the current device and developers have better control over who gets to use their applications.

"What about promo codes?" I think Apple has learned its lesson about free apps/promo codes. I'm betting that they've already thought about a way to distribute in-app purchases via promo codes.

"What about people who have already bought apps?" Admittedly, this news is currently best suited for new products than existing ones. Devs who have built in shared keychains already have a slight leg up but for the time being you'll likely want to at least consider a new product that leverages this ability rather than trying to retrofit.

As for people who have already bought a paid version whom you want to support while migrating to a free demo/in-app purchase model, you're likely going to encounter trouble until Apple irons out its policies and its solutions. Again, I expect Apple to provide some sort of solution shortly.

And why all this trust in Apple? Any move that benefits developers ends up benefiting Apple in the end. This was a smart move on Apple's part, it's a good move for users, and for developers too. And it still has a long way to play out so keep watching for Apple's next steps.

"Who are the biggest winners here?" It's the people who have been putting out free and ad-support apps. They now have a way to turn off those ads and to solicit donations. In-app purchase doesn't have to be about buying and unlocking features. It provides a real solution for free apps to monetize, and for Apple to transform a huge part of their store into a paying model.

"Can free app devs charge an in-app purchase for nothing (i.e. donation)? Can the user repeat purchases or pick the amount?" Apple provides several kinds of purchase types and those purchases can be applied in multiples. For example, you can buy 5 hit point boosters or make 5 donations of $1. So yes, that model does work for donations.

"Can devs now charge for updates?" Not unless those new features are added as unlockable items. Again, this is something that Apple will likely address given the great demand for exactly that. Expect to see new App Store terms of service should that happen because the current one uses a "buy once, use and upgrade forever" model.

"What kinds of limitations should I think about?" TUAW reader Scott Kveton suggest the following in the comments for this post. He writes, "The key is keeping the app under 10 MB so it can be downloaded without wi-fi. A lot of developers can just 'unlock' functionality but when you get into actually delivery potentially large(ish) content to the device that's not possible. It also opens up the possibility to make the apps that much smaller on initial 'purchase' and then download content on the fly."