Back when the iPhone Developer Program was first announced, developer provisions (the 'permission slips' that allow developers to distribute pre-release builds of apps in progress) lasted one year. It seemed natural to have a one year expiration, as our developer memberships also lasted one year.

Everything was all fine, developers created new provision profiles as they grew, and each lasted one year. However, sometime in May of this year, provision profiles seemed to start expiring after 90 days. At first, many thought this was linked to the expiration time of their iPhone developer memberships, which would decrease the time to use a provision.

However, it seems that it's been set that provisions are only going to last 90 days. Also, distribution provision profiles, which are needed to submit applications to the App Store or distribute applications via ad-hoc, now only last about six months instead of one year.

If your provisions are expiring, your iPhone will remind you to renew your provision, and will state when that provision will expire.

If this is the way it's going to be, we may have to live with it -- it's just something that I would like to stay consistent, rather than wondering every time I renew a provision whether Apple has swapped out its stopwatch again.

Sometimes Auntie TUAW gets emails from anxious iPhone developers. In this case, the correspondent is running into issues with Apple's new automated checks for private API use in iPhone apps.

Dear Auntie TUAW,

I got an email from Apple's App Review team saying the code in my iPhone app uses private APIs. They pointed to -setOrder, which is a method I created in code, and -setThumbnail, which was created automatically from a Core Data property.

But those are all from my own code, and thumbnail is actually a property for my CoreData class. Any idea why? I don't even have a setter for thumbnail, it is just a dynamic property for the CoreData class.

I don't want to rename my properties because I'm not sure that CoreData will automigrate my renamed items and my users are going to start crying if everything breaks.

Love & snuggles,

Lauren

Read on for Auntie's reply.

Chillingo recently announced that it would be launching Crystal SDK, a service joining the increasingly crowded social network market for iPhone games. Xbox Live on the Xbox is an official social network, but the iPhone has no such official service. A crowd of contenders, from the popular OpenFeint service to ngmoco's Plus+ network, are jumping in and trying to get developers on board with them. Crystal SDK is one of those -- they've now launched the official website and are asking developers interested to sign up and see what their software has to offer.

Like many of the other services, Crystal is offering to integrate challenges, achievements, leaderboards, and other social services into iPhone apps. The SDK seems like it's still pre-release, however -- there's only a signup, no information on cost or implementation or anything else on the site. Still, if you happen to be an iPhone developer still looking for a network to hook up with, they might be the one for you.

While we're at it: what do you consumers think? Have you actually chosen a network to go with, or are you doing what I'm doing and still basically going game by game? The goal of these networks eventually is to have a unified stable of developers, where you'll jump into a new game simply because it's linked to the network you're signed up with (and your friends will be playing over there and encouraging you to join). But in reality, I haven't seen that -- most people I know are just playing the games they're interested in, and the network the games are connected to hasn't made a big difference.

Well here we go. Up until now, we've heard a lot from developers about how much of a mess the App Store's approval process is, from people who've been rejected outright to people who've been forced to resubmit to people who've just given up completely. But we haven't heard much from Apple, and now Phil Schiller has spoken with Business Week about what it is about the App Store's approval process that has devs pulling their hair out.

The verdict? Schiller says the process is in place for a reason. About 90% of the apps submitted merely have bugs or technical issues, and he says for the most part that devs are happy to get that feedback (though TechCrunch doesn't buy that for one second). But the other 10% of the apps Apple denies are simply what they deem "inappropriate," which could be anything from problematic coding (code that steals passwords or other private information), or app content that doesn't belong on the store, from porn to apps that help break the law or steal in some way. Apple is also vicious about trademark defense -- Schiller says that "if you don't defend your trademarks, in the end you end up not owning them."

That all sounds fine and dandy (ok, well, the "inappropriate" label is a little unclear -- that's broad enough that Apple could fit almost anything under that umbrella, which is a bit troubling), but what about all of those angry devs? Unfortunately, Schiller doesn't address at all the idea that Apple might someday allow devs to release apps that haven't been through their approval process, on the App Store or anywhere else. As far as Apple is concerned, it seems like they're keeping their grip on what gets released, and anyone who doesn't like it is welcome to go elsewhere.

[via TheAppleBlog]

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.