Last week, TUAW showed you how to sign iPhone applications for informal developer-to-developer distribution. That approach lets you share applications between members of the iPhone developer program by using your signing credentials to authorize the application for use on your development units.

iPhone applications compiled for the Intel-based simulator can also be shared between developers. And, since the free developer program offers access to the simulator, the apps can be distributed even more widely than with the re-signing approach.

Simulator testing does not offer the full suite of device-specific capabilities. You cannot simulate the onboard camera or retrieve proper accelerometer feedback. The simulator does not vibrate or provide general multitouch input. (You can pinch, but that's about it.)

The strength of simulator-based distribution is that it lets you send out applications for early testing and feedback. Sim-only tests strengthen the preliminary design process; this approach helps solicit feedback on user interface and general program layout before the main development push gets underway.

Simulator-based apps are easy to transfer and easy to use, cutting out a layer of overhead that's needed for when you go to a full ad-hoc beta.

To distribute a simulator application, go to the Library/Application Support/iPhone Simulator/User/Applications/ folder in your home directory. There you'll find the application sandbox folders that are currently installed for your simulator. Each folder is named with a unique id (i.e. 56E66CE5...DC028F) that does not reflect the folder's contents.

You'll have to peek inside to determine which folder is which.The folder contains the application, and three sandbox directories: tmp, Library, and Documents.

To share a simulator folder compiled for 2.2.1 and earlier, you must zip up both the folder with the application and the .sb (sandbox) file that shares the same name as the folder. 3.0 and later applications do not use a .sb file. Just zip up and share the folder.

Install the shared app by decompressing its sandbox folder (and, for 2.x, its .sb file). The recipient must have installed the iPhone SDK. Drop it into the simulator's Applications folder on another machine and launch the simulator. The app should appear in the simulator, ready for testing.

Apple has released a 3.1 beta for the iPhone SDK. Both the SDK beta and firmware are available for testing and development to paid members of the iPhone developer program. As pre-release software, any details about this new release remain under NDA.

A pre-installation advisory and beta release notes are available as per Apple's usual release strategy. As before, you cannot use the 3.1 SDK to create applications for submitting to the App Store, so if you plan to download it be prepared to create a separate installation directory.

The new release comes just on the heels of the public 3.0 firmware. Its full-dot-number indicates that it contains more than just minor bug fixes (a relatively minor revision would probably be listed as 3.0.1).

Thanks to everyone who sent this in.

Have you seen anything like that already, where developers have said, well we thought about doing it this way, but we're going another way?

PR: Too early. The phones aren't even out yet, user experience hasn't occurred yet. I would say July, we'll get a lot of feedback once these games come out with push notifications. The other thing that's kind of interesting, by the way, is that OpenFeint is working on cross-compatibility, because if I have a 2.2 iPhone and you have a 3.0 iPhone, and you send me a social challenge, in my app on 2.2, it won't show up as a push notification, right, because I don't have the 3.0 iPhone. So we are support the concept of push notifications in the plumbing and infrastructure of OpenFeint, however on a 2.2 phone, whenever the user next opens the app, they would see a screen that is an OpenFeint screen that would have a notification saying "you've got to beat my score," as opposed to seeing it on the iPhone icon, as a number, like the Mail thing, where it says you have notes waiting for you.

So I think as a user experience, the jury's still out, because the platforms are just getting ready, right? So the key here is to say that we're going to make it trivial by continuing our tradition, which is no servers, very easy to integrate, and some big games will launch in July with push notifications and then we'll go from there.

I think, to a certain extent, the same thing will happen on the microtransactions side. It already has happened with Xbox Live -- I don't know if you remember the story of horse armor, where everyone says "how can you release a different graphic and ask us to pay for it?" Have you seen examples yet of how developers want to use microtransactions? Are they aware of that danger or are they fearful of that at all?

PR: So I think the obvious one, just because I have, as I said, investments in companies in the Facebook app space, the big reason for microtransactions is virtual goods. So any kind of virtual world, avatar apps, some of these Mafia iMob apps, you can assume that there will be virtual goods unlocking with microtransactions. That one I think will translate over fairly well, in fact Net is going next week to China, where he's a keynote speaker at Tencent's annual conference. Tencent is an Asian company which does a billion dollars in microtransactions, all of it virtual goods. So I think that microtransactions, as we see them on social networks today, will come pretty much that way onto the iPhone social network, or the iPhone gaming network.

NJ: I also think that it will actually lead to the pricing, might even drop dramatically, but those who are charging for applications are going to go free, because they're going to earn much more by making it free and leveraging microtransactions.

Yeah, if you're charging $4 for an app and can sell four levels for $1 each, that's the way to go.

NJ: The user starts playing, gets very engaged, and wants to get to the next level and make the purchase, and it's very difficult not to make the purchase if you're engaged and you want to continue the game.

PR: The thing that's a little trickier, I think, is when you have microtransactions that aren't directly virtual goods, because virtual goods don't fit the theme. But are like chapters, or just additional content in the game. Then, I think, the business model is a little trickier, because that's your content update strategy, and to some extent, the iPhone user is used to -- like, if you look at the success of Pocket God, it's a double edged sword. If you talk to the Pocket God guys, their game is one of the few games that stays in the top five constantly. It's just always in the top five. And they use OpenFeint, and they're going to use push notifications, but when we spoke to him about microtransactions, he said, I have to figure that out, because their commitment to their userbase is, every week you're going to get an update with more content. So given that he's already committed that on the current price point, how does he unlock more content with microtransactions? So he was the first to say I definitely want to do push notifications, but I have to think hard about how I could incorporate microtransactions into Pocket God. So I do think there's a little more complexity there, especially when it's not just direct virtual goods. But I think they'll crack it. I think some other people we're talking to are certainly thinking of Chapter 1, Chapter 2, Chapter 3, three microtransactions. And certainly the virtual goods guys are like no questions how they'll do it.

And there are definitely precedents for both, in terms of episodic gaming on other services. Jason maybe you can talk about this, too, as a developer -- I'm really interested in the balance between making sure that what you're selling people is worth it, or something that's not. If you're asking to pay a dollar for a gun that's just a re-skin, people won't go for that. What do you think of that?

JC: I think, as a game designer, what you have to really think about is the motivations for why people will want to purchase this content. Whether it's a re-skin or not is less important than what it will allow you to do in the game. And the reason why I think virtual goods have done so well on social networks is that social pressure is a huge motivator to getting people to do things, and if part of that social pressure results in you engaging and buying virtual content, people are much more likely to do it. I mean, if you just have another gun that allows you to increase your DPS by two points, that's not terribly interesting to anyone but the ultra hardcore gamer, and then they'll probably just be pissed off that they have to pay for it. So that's not really an appropriate way to go about it. As a traditional gamer, buying episodic content or buying level packs, or substantially new gameplay experience, fits with my head, and then virtual goods, I think, have to be motivated through social pressure.

And the last question I have is just about the future of OpenFeint. I have to give it you guys -- there were quite a few, and there still are, services poking around that want to do the kind of stuff that you're doing. And just in terms of size and influence right now, you're kind of the top of the heap. So what's next, are you planning to kind of sit on the heap and just keep things set, or are you still aiming to improve here?

PR: I think that definitely we will continue to innovate and add more services to the platform -- there's no question that it's a platform play, and that we will continue to add features and additional things. I would say two things: one is, we will publish games, always, on top of our own platform technology, that will really kind of push the borders of gameplay design around the OpenFeint platform, to sort of demostrate and lead the way. So in the last announcement, we did hint at a new game coming out this summer based around push notifications and microtransactions, where we want to lead the industry. Because we never think that by being in front today, that we will be always in front. So we want OpenFeint to be the premiere platform, we agree that today, we certainly feel like it's way up there, but we feel like you constantly have to build new product on top of your platform to really make a world class platform. Because otherwise you're just sort of opining and thinking oh, this is good stuff. So we always want to test our own platform, and expect a title this summer based on OS 3.0 and OpenFeint features.

The second thing, which is, I think we're really doing something different around the business model. Ngmoco announced their Plus+ platform this week, and it's really a publishing tool rather than an open platform, and we're pretty proud of the fact that we're sort of the biggest player who is really able to provide an open platform where a developer does not have to make a publishing deal with us in order to get access to the platform. Ngmoco's platform is hey, we have this platform, it's part of our publishing network, and if you want to publish games with us, that's how you get the platform, and obviously you know the economics of the publishing business in the game industry, right? There's revenue that has to be sacrificed there. So I think as a guiding strategy, we will never make our platform related to anything with our publishing because it's our belief that this OpenFeint thing does two things that we will always have to provide for publishers: no servers, because 90% of developers have no experience building servers, they build great console games, client side stuff, C, C++ programming, all this stuff, but they really don't have any backend experience. And two, we're not going to take rev share, in terms of publishing deals. And those two things, I think, are sort of our long-term guides. The third thing is to build our own games constantly, so we can use Danielle and Jason's game design and knowledge to say here's the kind of games we can do. So if we can do that and execute, I think, with some fingers crossed, with some luck, we'll emerge as the de facto standard, which is our goal.

I had talked to Danielle a little about pricing already, but I wanted to ask about microtransactions as well -- when you do that stuff, are you not skimming off revenue as it comes through, or what is the pricing scheme there?

PR: Well even today, we have cross promotion inside OpenFeint 2, even before microtransactions, where if two players meet in a lobby, and they're from different games, then one player clicks on the other player's game, and you go to the App Store and you buy that other player's game? That's what you call our one-touch iPromote product inside of OpenFeint, it's a big draw for a lot of developers, because our community is now three million and growing -- we call it our social bazaar, because the App Store is so cluttered now that it's hard to differentiate. So you use OpenFeint and get your game in front of three million people in these lobbies. That revenue, when someone buys a game using OpenFeint's cross promotion feature, doesn't come from the developer, it comes from Apple. Because we are an Apple affiliate, through BigShare. So we take the user into a webview, which is our own catalog, where you can buy games off the App Store, and then Apple actually pays us. So that's hopefully -- this is the same thing, the whole idea is to get Apple to pay us every time there's a purchase in the App Store, including in-app purchases, as opposed to the outside.

Great. That's pretty much everything I had to ask, was there anything else you wanted to share? I guess we'll keep an eye on the game coming out this summer.

JC: Yeah, I guess the only other thing worth mentioning is that OpenFeint is available now -- it can be downloaded by anyone from our website. It's real.

Cool. Thanks very much.

With iPhone OS 3.0 only having been released yesterday, two big companies are already angling to be developers' go-to for setting up push notifications and other online services for the new apps. OpenFeint was the first service we've heard about -- they have been offering social networking connections to developers for a while, but with the new firmware release, they tell us that they're also hosting options for both push notifications and microtransactions to their stable of app developers.

That stable includes apps like Pocket God and Aurora Feint (Danielle Cassley of both Aurora Feint and OpenFeint told us a while back that she was very excited at the prospect of microtransactions with 3.0), and both of those games, as well as others on the service, are planning to include push notifications with "social challenges" -- you'll challenge a friend to complete a certain goal in game, and then get notified when they meet that goal. Look for those new features in an OpenFeint app near you.

And OpenFeint isn't the only service jockeying for developers' attention -- Urban Airship is also making a bid to host push notifications for iPhone game developers. They've landed one of the first push-enabled games, Tap Tap Revenge, and are looking to offer push to more devs, along with in-app purchase support as well. They don't quite have the library together that OpenFeint already does, but their service integrates, they say, in just a matter of hours, and their aim is to make it "brain dead easy" for developers.

The floodgates are open, and we're sure to see more and more companies jump in on hosting plans like this in the future. Prepare to be pushed.

A new kind of App Store rejection is making the rounds in the iPhone World. It's not about violating the SDK. It's not about objectionable content. It's about Apple empowering its reviewers to reject software without providing any substantive reason or feedback. TUAW reader Kenneth Ballenegger received the following rejection notice for his iLaugh application.

This kind of rejection is a gamechanger. Devs have complained that Apple's review policies to date have been inconsistent and arbitrary, since it was relatively easy to compare rejections and demonstrate the multiple standards in play. This rejection shields Apple's internal processes even further. Instead of moving towards transparency and responding to developer concerns, Apple has pointed itself in the opposite direction.

Making this rejection sting more, the app already was in the App Store; this submission was a bug-fix update. The premium edition of the same app, submitted at the same time, was approved without issue. It seems that previous and current approvals for the same application would argue in favor of letting this version through, or at a minimum providing an explanation of what's wrong with this one. As Christina posted yesterday, developers aren't getting straight answers about App Store rejections, even at WWDC.

"Sole discretion" hides a lot of possible review errors, both subjective and accidental. It makes it harder than ever for smaller companies to appeal rejections and denies them a factual basis on which to evaluate whether their rejection was issued in error. It also gives a firm answer to those who have been hoping for a transparent ticketing system and a open appeal process. Apple isn't interested; it's their store, their rules, and Caveat Developer to anyone whose business plan depends solely on Apple's beneficence.

An app full of admittedly lame jokes might be an appropriate candidate for App Store rejection, but the combination of veto power, the opaque review/appeal process, and inconsistent and capricious application of Apple's ax adds up to a troublesome situation in the developer ecosystem and in the App Store.

Postscript: Kenneth writes in to clarify that the 1.1.1 bug-fix update submitted 3 months ago was rejected. This will not affect his 2.0 Lite version, which was just submitted.

One of the relatively unsung features of the upcoming iPhone 3.0 firmware is that the new version of Safari for iPhone will use geolocation. This means that the browser can request location information from the iPhone's GPS receiver, and can also provide that location information to websites that you're visiting.

ComputerWorld's Seth Weintraub reports that the beta versions of the firmware are working well with sample web-aware websites. This capability is not only planned for the iPhone's implementation of Safari, but many upcoming browsers for Mac as well.

Geolocation capabilities make it simple for developers to create web apps that no longer need to ask you for an address or zip code. Google, for instance, is planning on making their Latitude application a 3.0-only web app rather than a standalone application on the iPhone. Latitude will leverage the geolocation features of Safari by knowing exactly where you are at a particular point in time and sending that info to the Latitude servers, then returning the whereabouts of your friends while informing them where you are.

For those of you who don't want your 3.0-enabled iPhone to let the world know exactly where you are, remember that you can always turn off Location Services in the General Settings or just answer "Don't Allow" when asked if Safari or a particular website would like to use your current location.

Sure, the transparent email and the yet-another-dialer brigade are all well and good, but there are a few things the iPhone doesn't do that I really wish it would. Here's a pair of app suggestions that are probably outside the bounds of the SDK and prime fodder for jailbreak developers, but if someone came up with a way to do them that would make it onto the App Store, I can guarantee you at least one customer.

WiFi Master: If you use your iPhone in a major metropolitan area, you've probably encountered the problem I have in New York City -- scores of access points named 'linksys,' 'netgear' or 'default' or a Starbucks broadcasting AT&T's WiFi network on every corner. Join one, just once, and your iPhone insists on hopping aboard whenever it's in range, whether or not the named network is the one you meant to use or whether you've signed into the web portal for the WLAN (leaving you starved for connectivity, as the 3G connection is superceded by the WiFi link).

Tweaking the network settings is generally a no-no for non-Apple apps, but we need help. Give me a quick way to turn WiFi on and off from the home screen, a way to exclude or include access points by MAC address instead of just by SSID (locking out the rogue 'linksys' networks), and instant display of my assigned DHCP address without diving four screens down into the Settings app. Granted, the Devicescape sign-on automation apps are a good start towards this goal (the Easy WiFi for AT&T iPhones app is worth the $0.99 in aggravation reduction) but I need more active WiFi control in this network-dense environment.

As noted in the comments, the jailbreak app SBSettings covers a lot of these use cases; if you're in a WiFi hot zone and you can't take any more, it might be the tool that pushes you to jailbreak your phone.

GotThis?: One of the favored activities of appoholics, when meeting in their secret underground lairs, is comparing screenfuls of cool iPhone apps to see what they might want to download next. It would be easier if these phone-waving sessions could be automated with -- of course -- an app that would compare your installed suite with that of your neighbor's, point out what he's got that you don't and vice versa, show you most-run statistics and then perhaps link you to the App Store if you've gotta have one of those apps right away.

The problem is that the roster of installed apps is not accessible to a sandboxed app running on the phone, at least not under SDK rules; one way to do this would be to scrape the installed app profile from iTunes and then store it, with the user's permission, on an external website (leveraging the existing iUseThis for iPhone, perhaps). Give this app the interface and location awareness of contact sharer & billionth-app Bump, let users tap iPhones to compare installation profiles, and you'd have a fun social networking tool plus an appoholic enabler of devastating proportions.

What's on your app wishlist? Have you seen apps like these, either in the App Store or in the Cydia Store? Let us know below.

If it's Monday, there must be a few more stories of iPhone apps rejected for curious and spurious reasons. Today's contenders are up to the line... and away they go!

First, it's Maza's Drivetrain app, a remote control for the Transmission client for Bittorrent running on the user's computer. Rejected! In this case, the reason is that Bittorrent is sometimes used for the trading of third-party copyrighted material. Yeah, but... um... the iPhone app isn't a torrent client at all, it's just a UI for a client running elsewhere. How does that make any kind of sense? iLounge quotes the developer as saying the rejection is "ridiculous," and it's hard to disagree.

Second, if you've ever wanted to replace the face of Jesus with your own, well, you can't do it with an iPhone app. SAI reports that the developer of the previously-approved Animalyzer (which let you replace animal faces with your photos) has gotten a rejection notice for the Me So Holy app that extends the face-replacement to religious figures. Apple's justification for the rejection is the catch-all "objectionable content" clause 3.3.12 of the developer agreement, which states

"Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple's reasonable judgement may be found objectionable by iPhone or iPod touch users."

Could one reasonably judge that some iPhone or iPod touch users might object to an app that lets users replace a divine visage with a mugshot or LOLcat? Sure, they might... but when an app that lets you aim virtual urine at a toilet sails through to the store without a hiccup, 'reasonable judgement' doesn't seem to be a valid operating standard any longer. There are hundreds (if not thousands) of 'offensive' apps in the store already -- but offending religious sensibilities is clearly different than grading feces.

[via Engadget & Techmeme]

Version version, who's got the new version? iPhone OS 3.0 beta 5 is now downloadable, along with a new build of iTunes 8.2 -- log into developer.apple.com to pick up the latest build.

What's tweaked and changed? Well, editing the carrier file in iTunes to enable tethering is now apparently blocked, and MMS support on AT&T is also 'hidden' per the iPhone Blog. It's not 100% clear whether these feature drops are deliberate, as some reports say a clean install preserves the capabilities. Parental control features for apps now seem to be visible... and yes, the new beta has already been jailbroken.

Got more observations and tidbits? Let us know below.

Thanks to everyone who sent this in.

I love hearing this about the iPhone: the San Francisco Chronicle has a piece about how Apple's little revolutionary telephone has brought a whole new crop of programmers into the development mix. People who had never before looked at code or considered writing their own applications are getting ideas about how to make better software, picking up Cocoa and Xcode books, and going to town. And strangely, we might actually have fart apps to thank for this -- people aren't just seeing the iPhone as an innovative platform, but they're seeing the App Store as an "anything goes" environment, where even their silly little idea might work.

I don't know if we can pin all the credit for the burgeoning iPhone development scene on fart apps and the impression that even a monkey can make bestselling iPhone software (certainly Apple has set the bar and price for entry pretty low, both with the extremely cheap $100 fee for a developer account as well as the high quality Xcode software that comes on every Mac), but there is definitely something in this little device that's driving people to try and create their own software for it.

Oh, and the money probably helps, too. Still, whether people are taking up iPhone development because they want to make millions or are just looking for another hobby, it's us, app consumers, who will benefit.

In the last iPhone Dev 101 post, I told you a little about creating your first project using Xcode; however, in this post, I want to show you how to create your first application that will run in the iPhone simulator. In honor of staying with the classic way of teaching programming, we'll create a "Hello World!" application as our first one.

Creating the new project
If you have installed the iPhone SDK/Xcode, then you can launch Xcode by navigating to /Developer/Applications. Once there, you can double click on the Xcode application (you may also find it handy to just drag the icon to the dock if you will be using it a lot).

Once Xcode launches, click File > New Project. Under the iPhone OS section on the left side of the resulting window, select "Application." Select "View-based Application" from the templates that show up on the right side, and then click the "Choose" button. You will then be prompted to specify a project save name -- this will also be the name of your resulting application, so choose your project name wisely.

You're project has now been created, and the Xcode window that is displayed will contain all of your code, resources, etc. There isn't much there now, but the application is fully functional at this point. You can click the "Build & Go" button in the toolbar, and the application will be compiled and launched in the iPhone Simulator. Again, this is a fully functional application, but it doesn't do anything useful at this point -- the usefulness of the app is up to your coding, but Apple supplies you with the base code and dependencies.

In anticipation of the Apple Worldwide Developer Conference coming up June 8 - 12 in San Francisco, Apple has posted four videos highlighting developers who are creating apps with the iPhone SDK.

Each video shows how the developer is creating a unique app with the iPhone SDK, using the tools and frameworks, and then selling the app through the App Store.

The videos highlight:

• Dr. Ge Wang of Smule, the developers of Ocarina and Leaf Trombone: World Stage (clicks open iTunes), among other apps. He is an assistant professor at Stanford who researches
• Christina Wick, who is part of the Mac software team for AOL (parent company of Weblogs Inc. and TUAW). Christina's team is using the SDK to develop iPhone versions of many of the AOL Mac applications, including AOL Radio
• Werner Jainek of Stuttgart-based Cultured Code, the developers of Things for Mac and iPhone. Things (click opens iTunes) is an amazing task management app that is a favorite of several TUAW bloggers.
• Steve Demeter of Demiforce is a lifelong gamer who saw the potential of the iPhone as a gaming platform and who has had great success with his app Trism (click opens iTunes).

In this cynical world, it's great to see four people who are so positive about the iPhone platform and the SDK.

But you knew this, right? Fire up your downloaders, another update from Apple means the digging has already begun for a) new features or updates, b) hints for a new iPhone.

Thanks to everyone who sent this in! I'd like to note that we broke this via our Twitter feed several hours ago. Even if you don't "do" the Twitter dance, it's a good way to catch breaking news.

Former TUAW blogger Erica Sadun has a cautionary post for developers regarding the pending push notifications coming to iPhone OS 3.0: better get yourself some reliable servers. The implication, delivered via headline, is that smaller developers won't be able to afford push notification. Indeed, as Erica says, coding for an app that can run in the background is one thing -- you may need to scale things down a bit for resource management -- but deploying a reliable push notification system is a tall order by comparison.

Instead of coding once and deploying, developers will now have to manage servers to handle the load of users who will be receiving push notifications. This ongoing server maintenance issue is the sort of thing we used to laugh about when digg first started, or Twitter, or MySpace, or any number of services that grew a little ahead of server capacity. After speaking to one of the network engineers at Twitter during SxSW this year, I don't envy the task of staying ahead of these curves. But push, in my opinion, isn't as onerous as that.

Push notifications aren't serving entire pages. The difference in data throughput overall is much slimmer than even the light pages Twitter serves. Erica correctly points out that in aggregate, the push server might be hit pretty frequently; however, and there's more of a concern with reliability for a finance or medical app than something like Twitter or digg. But even when you throw in the added hurdle of security I'm guessing the resources for this are available at a reasonable cost.

I get that this is more work for developers, but Erica makes it sound a little threatening, like developers' only resolution will be to cobble together a mighty datacenter from spare computer parts. My assertion is that developers who wish to play the push game will simply need to look for outside resources and factor that into their price. Maybe fewer $.99 apps is a good thing? You certainly don't need 30 apps trying to alert you during the day -- how would you get anything done?

In the end, push notifications are welcome, and I'd rather have that than a one-hour battery life for the day. Plus, I would agree that some smaller developers will have to forget push because the potential costs are too high. Guess what? That's as it should be. If your product requires it, your cost should reflect it. There's no shortage of service providers out there, and as we've seen in the past (look at the podcast services that popped up when that blew up a few years ago) the market will fill the needs of the developers if they aren't in the business of making their own server farms. It's certainly a new twist to the iPhone dev game, and it's an opportunity for someone who can deliver a reliable push framework at a reasonable price -- perhaps one running atop Amazon's EC2, Google's App Engine or even Microsoft's Azure cloud service.

Danielle Cassley took one of the strangest paths you might find to game designer -- just out of a computer science degree at Berkeley, she was trying to get a job as a babysitter when she met Peter Relan of the YouWeb Incubator. And rather than have her take care of his kids, he decided instead to put her in an idea farm and see what happened.

Aurora Feint was what happened -- she and Jason Citron, full of ideas, created a game in just ten weeks that took over the App Store out of nowhere in its infancy. The game originally released for free, and while it promised to be an MMO, it started out as a puzzle/RPG game -- people didn't quite understand what it was, but they liked it anyway.

Almost a year later, Aurora Feint has spawned four different versions and even a social platform, and Danielle and Jason are still full of ideas. In this exclusive interview with TUAW, she talks about how Aurora Feint came to be, what she thinks of the App Store so far (and if developers will ever be able to charge the prices they want), and what's next for the Aurora Feint series (they've just released a new version of The Arena called Daemons) and the iPhone platform. Click the link below to read on.