If you're wondering what exactly this is, the Cycript page offers some examples of code written with Cycript. Basically, it allows you to implement full JavaScript commands, while working with Objective-C in the same project.

Cycript is dependent on the MobileSubstrate and libffi libraries, which are available in Cydia. This won't be used to develop applications in the App Store anytime soon.

If you're interested, you can download examples or releases of Cycript. It's still being worked on, but if you're developing with both Objective-C and JavaScript in a project, you should check it out.

Touch Arcade has the news that the long-awaited Ravensword and a number of other games built on the Unity game engine have been rejected by Apple from the App Store. The problem appears to be a number of API calls in the engine (though not specifically the game themselves, as I understand it) that allow the games to access the iPhone's number and send it back to the developer's servers.

Apple considers these to be private APIs, and they also got games developer Storm8 in trouble earlier this week; their games were pulled from the store in response to a lawsuit alleging that they were collecting data from users without their knowledge.

Chillingo, publishers of Ravensword, contacted us about this story, and they said that while the Unity engine does allow developers to use these calls, they did not use them or collect any user information. We're also told that the problem APIs "have been removed," and Chillingo has resubmitted the game for App Store approval.

As I understand it, this is the same type of issue that came up with Google a while back. It's not the same APIs (Google was using the proximity sensor back then), but now as then, it's Apple's call whether they will allow developers to use these private and undocumented calls. Obviously some apps on the iPhone have to access the address book from time to time, but it's Apple's call whether they can use APIs like that or not. This time, it appears, they said no.

Update: Unity has also contacted us, and they say that the engine was updated to Apple's wishes as soon as they learned of the issue. They also would like to point out that while Storm8 did use the same private API calls, they don't use Unity to run their games. Storm8's update on the issue is here.

We mentioned Gamesalad's plans to bring their publishing system to the iPhone earlier this year, and now they've done it: for $99 a year, they say that you'll be able to design games on their game creator development tool, and then publish them straight out to the iPhone's App Store. If you don't want to bother publishing the games yourself, you can create them and have them "viewed" through the Gamesalad Viewer (which we couldn't find on the App Store quite yet), or you can export them out as full applications and publish them as your own iPhone apps (Flutterby is in the store right now as an example of a Gamesalad Creator game).

There's also a $1999 membership service that lets you customize every aspect of your games, and provides you with direct customer support, which is supposed to be for "elite users" (like, we guess, actual game companies). And truthfully, I've developed a few apps using just Xcode, and it's not too big a deal (though I've never had to go through an actual release or worked with end users, which I'm sure is most of the battle anyway). But if the thought of using professional coding tools to develop your little game idea sends you into panic attacks, and the Gamesalad creator seems more your speed, this might be a nice viable way for you to turn your gaming idea into App Store gold.

It costs nothing to download and try out the creator, so if the idea interests you, you can work on putting a game together, and then pay later when you decide you've got something you want published on the iPhone. And hey, if you do put a game up, be sure to send a tip and let us know -- we'd love to see the end products of this process.

Have you ever wanted to work with rather deep elements of Core Foundation in the iPhone SDK with some sort of front end? August Joki has just come up with a project that provides a Cocoa Touch wrapper for the CFStringTokenizer type in the Core Foundation framework.

As you can see in the screen shot at right, the demo provides various aspects about the current string including the string in a letter, word, or using a WordBoundary. It works just like CFStringTokenizer can, but can be accessed using this front-end.

If you're wondering what CFStringTokenizer actually is, it's useful for breaking a string into a token, which can specified by words, sentences, or paragraphs. You're also able to further modify the tokenization once you break it down.

This is something that's going to be useful for iPhone developers who like to work with a Cocoa Touch interface to bring lower-level elements of the iPhone OS into their apps, and also to developers who work with natural language strings.

To download this project, go over to the cocoa-stringtokenizer project page on GitHub.

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

How hard is it to make a living at App Store? Are the naysayers right? Do you need a full-fledged business plan and established company even to step through the door? Or can you make it as an independent, finding your own fortune and success. Today, TUAW talks to a handful of App Store developers to hear their stories and discuss their experience.

Today's scheduled panelists include Bryan Mitchell, author of the extremely successful Geared game for iPhone, Scott Lawrence, developer of LlamaSlate, LlamaClock, among others, Darrel Plant, creator of Bedeviled, a puzzle game, Youssef Francis of Brancipater, developers of FlowChat (an iPhone IRC client), and Jonathan Zdziarski, author of the best Nintendo emulator that never made it to App Store, plus an Amber Alert app that did. Jonathan is also the author of several iPhone books.

We'll be chatting about the challenges and rewards of App Store: how the little guy can make it big, and how the little guy can get beat down. Join us for this live chat and bring your questions.

Read on for the chat

Is the App Store working just right? That's what Mike Schramm wondered the other day after this Newsweek article appeared, discussing the state of publishing apps on App Store. Tomorrow, we'll be hosting a live chat with real App Store developers, both successful and struggling. Please join us. You'll have a chance to hear about the current state of iPhone development and ask your questions about whether App Store is a gold rush, a business opportunity, or a disappointment.

(Full disclosure, I was interviewed for the Newsweek article, although I do not appear in the article itself.)

So there's still no Flash in Safari, but once Adobe hatches Flash Professional CS5 you'll be able to port your wacky Flash games or animations out to real, live iPhone/iPod touch apps. Yep, ActionScript 3 nerds rejoice: that tasty App Store pie will soon be yours, never minding the whole plug-in debate.

This is truly quite awesome in one regard, as it lowers the barrier to entry for some app developers, and will ease the port of some cool online games that we've seen floating around the interwebs. Then again, if you've spent a little time at places like Newgrounds.com, you will quickly see the dark side to this announcement from Adobe. All those crummy Flash toys online just got one step closer to coming to life on the App Store (we're guessing most will sell for the low, low price of $.99). At this rate there will be more apps than iPhones!

Still, back when I taught animation and game design, we had a lot of fun playing around in Flash for the powerful prototyping capabilities, if nothing else. It would have been cool to test games on the iPhone so easily. The video on Adobe's site looks pretty cool, with them touting the "responsiveness" of apps. Yeah, unlike the slowpoke performance my kids suffer on our G4 Mac when playing Flash games, eh? I get it -- when Unity 3D for iPhone came out there were problems with performance (it has matured nicely now), and any tool that exports in this way (turning an .fla into an .ipa, essentially) is bound to suffer from performance. Does anyone else find it ironic that a plug-in that was designed to make multimedia on the web lighter has become one of the most bloated? I digress.

No word on what SDK features are supported yet, but you can sign up for the demo when the beta starts. Those SDK features could be a killer, of course. If you can't leverage some of the features on the iPhone (multi-touch, GPS, camera, etc.) these may be relegated to the Entertainment category. One other thing to note about all the CS5 applications: they will be Intel-only, Cocoa and 64-bit native.

Update: Well, lookee there, apparently some games in the store have been using this already. Did you know South Park Avatar Creator was made using Flash? Amazing.

Part of my work requires me to mock up iPhone apps, often to show developers how I would redesign a user interface to work better than something they've come up with. Over the past few months, a number of paper sketchbooks have appeared on the market, all designed expressly for this purpose. I decided to try out all of the sketchbooks that I could find in a cursory Google search, just to see which one would work best for me. Of course, that meant that I had to write a review!

The three products I discovered and tested were App Sketchbook (US$16.99), iPhone Application Sketch Book (US$14.99), and The Developer Sketchbook for iPhone Apps (US$19.99). All of them are designed for the same reason, to let iPhone devs or business analysts describe how they want an application's user interface to look. Follow along as I take a look at these three sketchbooks, as well as a metal stencil template for drawing UI elements.

One sign that the iPhone development world is starting to mature is that companies are beginning to build the infrastructure necessary for devs to enable push notification and in-app purchasing. Usually these functions require a developer to make a significant investment in server hardware and labor to set up and operate the push and/or purchase servers, as well as to write code to integrate those services into their apps.

I met with Tim Courtney and Chris Grove of KeyLimeTie yesterday at 360iDev in downtown Denver. Their company's new service, iLime, is a scalable solution consisting of highly reliable server infrastructure and a set of iPhone Application Programming Interfaces (APIs) that make it possible for iPhone developers to integrate Apple Push Notification Service (APNS) and in-app purchase easily.

iLime is making it very easy for small, independent developers to test the waters of push notification by making their APIs and server prowess available for free for up to the first 25,000 push messages each month. After that point, the service is charged on a per-push basis on a tiered pricing structure that makes higher volume more attractive. For in-app purchasing, iLime simply charges a flat US$0.05 fee for every content purchase made through their service.

iLime was first announced at iPhone Dev Camp in August. At 360iDev, iLime announced additional features and detailed documentation of the APIs. Courtney also noted that while there are only a handful of apps in the App Store at this time using iLime's services, several hundred iPhone developers have tested and used the services and they expect a significant number of iLime-enabled apps in the near future.

It's great to see KeyLimeTie making the investment in the virtual bricks and mortar that enable push notification and in-app purchasing, so more iPhone devs can take advantage of these iPhone OS features.

Just after reaching 1 billion downloads five months ago, Apple announced this morning that the iPhone App Store has reached 2 billion downloads since its launch in July 2008. Also, Apple announced that 85,000 apps are available to download or buy from the App Store, and there are now over 125,000 registered iPhone developers with the iPhone Developer Program.

These apps are available now to the 50 million devices running the iPhone OS (iPhone/iPod touch), creating an ever-expanding group of users.

As part of Apple's efforts to make the ins-and-outs of the App Store more clear to everyone, Apple has just Introduced the App Store Resource Center. Apple states this new site is "a single destination where you can find everything from how to prepare for submitting your app to managing your app once it been posted to the App Store."

Basically, this new site offers an easy way for developers to read over and learn the many different policies and details about the App Store. It covers app submission, the App Store approval process and managing your app details, among other things There's really not much new, but you maybe able to find stuff easier now instead of looking through large PDF App Store guides.

If you're one of those developers who feels lost around iTunes Connect, you'll probably want to look over the guides in this new site. Anyways, if you're a registered iPhone developer, check out this new site, you just might learn something, maybe.

It's a Menlo world in the new Snow Leopard Xcode. 10.6's Xcode uses the Menlo Regular-11 font for the standard Xcode template. If you miss Monaco (and I know I did), it isn't hard to restore the look and feel of Xcode 10.5's defaults. That's not to say there's anything wrong with Menlo. Menlo is a lovely font. It's just not a familar font and some strange part of my brain keeps freaking out every time I look at the screen.

I'll probably force myself to adapt to Menlo at some point but for the moment, I'd rather just stick with Monaco. So to do that, here are some quick instructions. As you'll see you'll need to create a new theme based on the Xcode default theme and update its font settings.

To start, open Xcode > Xcode Preferences (Command-,). Choose Fonts & Colors. Select the Xcode Default theme and click Duplicate. Enter a name for the new theme (e.g. Normal Xcode Theme) and click OK. Select the new theme, and then select all categories within the theme. To do that, click on any item and then choose Edit > Select All (Command-A).

With the categories all selected, double-click in the font column. A font panel appears. Select Monaco 10 in the font panel and then close the panel. Click OK in the preferences pane and boom. You have returned to a font comfort zone.

Got any Xcode font preferences? Can you recommend a font that's better than Menlo, Monaco, or the good old standby Courier? Let us know in the comments.

Here's yet another interesting take on the burgeoning App Store environment. A company called Gendai Games has a game creator IDE/app called Gamesalad, designed to let you put together rapid prototype-style games for the Mac. They've been doing this for a while, and they even let you export your games out to the 'net using an online portal. But here's the kicker: they're also planning to let you take those games right out to the iPhone.

Their roadmap page talks about downloading to a test iPhone straight from a Mac, but presumably, they'd either have their own app on the App Store in which you could play your games, or even output it to some sort of wrapper app that you could then release on the App Store yourself. Their press release says they will allow for games "to be sold and marketed on the App Store," and that seems to us like there's compensation involved somehow, either through their portal, or through Apple's setup.

Very interesting. Unfortunately, most of this is forthcoming -- their development environment is available for a free download right now, so you could start working on creating your masterpiece right away if you want, but you'd have to wait until sometime "in the next few weeks" to see what iPhone features they have planned. Part of the iPhone's draw as a programmer's platform is that it's relatively easy to develop for, and an environment like this promises to make it even easier and more accessible. Whenever you have a low barrier of entry to development, release, and sales, you end up with two things: a market possibly flooded with junk, but on the other end, lots and lots of creativity.