With the apparent iPhone 4.0 SDK ban on cross-compiled code, Adobe has begun firing back at Apple. The New York Times Bits Blog carried the following statement from Adobe:

We are aware of Apple’s new SDK language and are looking into it. We continue to develop our Packager for iPhone OS technology, which we plan to debut in Flash CS5

The TheFlashBlog (which readers might remember from iPad porn posts past) took it far more personally:

What is clear is that Apple has timed this purposely to hurt sales of CS5. This has nothing to do whatsoever with bringing the Flash player to Apple’s devices. That is a separate discussion entirely. What they are saying is that they won’t allow applications onto their marketplace solely because of what language was originally used to create them. This is a frightening move that has no rational defense other than wanting tyrannical control over developers and more importantly, wanting to use developers as pawns in their crusade against Adobe. This does not just affect Adobe but also other technologies like Unity3D.

[...] Now let me put aside my role as an official representative of Adobe for a moment as I would look to make it clear what is going through my mind at the moment. Go screw yourself Apple.

The timing does seem interesting. Apple could have put this in iPhone 3.2 for iPad. They could have skipped iPhone 4.0 betas and put it in the final iPhone 4.0 GM release (rendering wasted all the apps (time and money) developers had built using CS5 between Flash release and iPhone 4.0 release).

The timing could be to hurt Adobe CS5 sales (though certainly lots of creative professionals use CS5 for reasons that have nothing to do with Flash cross-compiling) or it could be an advance warning to developers not to use those tools because they won't be allowed (or perhaps even compatible) with the final iPhone 4.0 release. Spending several months making an iPhone app in CS5 and then not being able to run it under iPhone 4.0 would be worse.

Ultimately, the language used by Apple is unclear and everyone is going to waste a lot of time and worry until it's clarified.

Daring Fireball discovered that, as part of Apple's newly released iPhone 4.0 beta, the licensing agreement now seems to ban binaries compiled by Adobe's upcoming CS5, Mono Touch, and the like:

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This seems to mean that cross-compilers, which let you develop in the soon-to-be-announced Adobe Flash CS5, the C# and .NET-based Mono Touch, or similar environments and spit out iPhone-compatible binaries at the end, are being prohibited.

Unity, which is used by many large iPhone game developers, creates Xcode Cocoa touch projects (the native iPhone frameworks) rather than binaries so it may not be effected. Given the importance of iPhone gaming and the companies developing them, it's hard to see Apple going hard-line against them the way they're stamping so very firmly on the neck of Adobe, Mono, etc. here.

As to the reasoning behind this change, Daring Fireball posits:

And, obviously, such a meta-platform [Flash or Mono sitting on top of Cocoa] would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

In other words, it once again highlights Apple's device-centric philosophy. They want beautiful boxes that run commodity apps and services. Adobe, Mono (even Google) want commodity boxes that run their apps and services. Those diametrically opposed points create these conflicts.

Pragmatically, selfishly, and completely from a user's perspective however, I'll take great, dedicated developers making apps specifically and purposefully for the platform (in this case, iPhone) any day over the code-once-spit-out-everywhere approach that has never delivered on that promise (other than with ugly, janky Air and Java apps).

Adobe CS5 with iPhone compilation launches in less than a week.

iPhone, iPad, and iPod Touch developers: get yourself over to Apple's developer center, as iPhone SDK 3.2 Beta 4 is ready for you to download, a mere two weeks after Beta three was unleashed for your coding pleasure. As MacRumors and Engadget note, it's too early to say what magical new capabilities are to be found here - but don't let that stop you.

The Electronic Freedom Foundation (EFF) petitioned NASA (an iPhone developer - iTunes link) under the Freedom of Information Act to provide them with a copy of Apple's iPhone SDK License Agreement, and have gone through and provided both a link to the agreement (an older version, provided at the time of the request) and some analysis of what it contains.

For those not familiar with the document, it contains the legal terms a developer must agree to before they can develop for the iPhone platform. Since the EFF and Apple have been duking it out over Jailbreaking for a while now -- the EFF wants Jailbreaking to be made an official exception to the Digital Millennium Copyright Act (DMCA) and Apple has opposed that move -- the EFF thinks the SDK agreement is particularly interesting at the moment.

The major points brought out and up by the EFF include:

• One rule of the SDK license agreement is you can't talk about the SDK license agreement. Despite it not being "Apple confidential information" developers are contractually prohibited from discussing it in public.
• Apps developed using the SDK can only be released through the iTunes App Store. So if Apple rejects you for any reason, according to their own guidelines or just on whim, you can't release via Jailbreak or on a competing platform (if any were compatible).
• No reverse engineering or helping others reverse engineer, even where such actions have legal precedent as exceptions to copyright.
• No hacking or helping hack any Apple products. That means no Jailbreaking the iPhone, no putting Boxee on your AppleTV, no loading Linux on your iPod Classic.
• Kill switch is informed in the agreement. Apple can revoke your certificate at any time. (Though they've yet to ever do this).
• If Apple messes up and owes a developer damages, those damages will never exceed $50, so good luck suing for millions over your rejected Sexy App or RSS Template.

The EFF is none to pleased at the one-sided, gate-kept, stifling terms of the SDK Licensing agreement and good for them. And good for us as well. The way we look at it we need the opposing forces of Apple Legal and the EFF always pushing for more on both sides. Apple's going to want to protect themselves as much as possible and the EFF is going to want to show us every way they're doing it so if we don't like it, we can voice our concerns as well.

We've used the analogy of restaurants before. The iPhone is Apple's boutique, haut-cuisine eatery. They set the menu. You can't go there, demand a burger, and then throw a fit when they tell you they don't serve it. (Well you can, but you'd be nuts -- Apple's not in the business of serving burgers). Instead of Gordon Ramsey you get Steve Jobs crafting your dining experience, and if you go there, that's what you should expect -- to trade control for ease of use (as opposed to Google where you trade privacy for free service). However, the EFF making sure the ingredients are what we're told they are, and that the kitchen is kept clean and compliant with local ordinances -- that's good for us, and ultimate it's good for Apple.

Check out the EFF article, take a look at the agreement, and let us know what you think.

[Thanks to Fassy for the tip!]

UPDATE: We're getting really scattered reports, but it looks like the site has a new look/feel, a new $99 developer option for Mac (to match the $99 iPhone option), and...? Let us know if you see anything else.

Also, some developers have told us that their registration no longer works after the update, so there may be some bugs at work. Let us know if you're having any problems accessing iPhone 3.2 or other resources.

ORIGINAL: It's not the Apple Store, but 9to5Mac is reporting that Apple's iPhone SDK developer portal, developer.apple.com is down:

We are busy updating the site. Please check back soon.

We know it won't be new MacBooks, so any guesses as to what it will be? We'll update as soon as we know!!

First it was McGraw-Hill on CNBC, and now it's Apple's own iPhone Developer Program leaking iPhone-relevance about tomorrow's "Come see our latest creation" event with the text "Place holder Agreement -- Need to update this for the 27th launch"

Will the iPhone agreement cover an iTablet/iSlate/iPad SDK as well? Will the iTablet be running the iPhone OS as rumored? Will iPhone 3.2 or iPhone 4.0 (or both) be announced for developer beta? Will there be no end to pre-event leaks?!

[via Engadget]

To go along with iPhone OS 3.1.2 (and the iPod touch equivalent) released earlier today, Apple has sent an email to registered developers informing them that:

Phone SDK 3.1.2 is now available on the iPhone Dev Center. If you have updated your development devices to iPhone OS 3.1.2, you will need to download and install the new iPhone SDK to continue your development.

A version of iPhone SDK 3.1.2 is also available to developers who are running Mac OS X Snow Leopard. Please ensure you select the appropriate SDK based on your development environment.

Apple has now weighed in with regards to AT&T's announcement today that they would be changing their policy and allowing VoIP (Voice over IP) to operate over their 3G network (something they'd previously asked Apple not to allow). When reached for comment, Apple spokeswoman Natalie Kerris told TiPb:

We're very happy that AT&T is now supporting VoIP applications. We will be amending our developer agreement to get VoIP apps on the App Store and in customers’ hands as soon as possible.

Hopefully this means users on other carriers, liberated by AT&T along with the rest of us, will now also get VoIP over 3G apps. If any international carriers do decide to ban VoIP themselves at this point -- yeah, we don't see that going over well at all.

Ars Technica is reporting, and posting the relevant legal language to back up, that the iPhone Developer Program License Agreement now contains language that says:

registered developers can no longer jailbreak their own phones or assist others in jailbreaking their phones, including (but not limited to) working on projects such as QuickPwn or PwnageTool. Developers are also forbidden from using the iPhone OS, SDK, or other developer tools to develop applications for distribution in any way other than the App Store or Ad Hoc distribution—which of course rules out distribution via Cydia, free or otherwise.

Of course, this won't prevent iPhone Dev Team from working on future jailbreak-related projects, but Ars rightly points out it may make legit iPhone developers hesitate in helping them out. From Apple's point of view, this is understandable (they want control of their platform and revenue stream), but from the point of view of certain types of developers and technology enthusiasts, it's untenable.

However, it remains to be seen what, if anything, Apple can or -- more importantly -- would do when it comes to enforcing this agreement.

As part of their just concluded iPhone OS 3.0 Preview Event, Apple refreshed the iPhone SDK and announced over 1000 new API for developers which, according to Senior Vice President of iPhone Software, Scott Forstall, are designed to better help developers make great apps. (And a boatload of money for all involved, 'natch).

Highlights include:

• In-app purchases, which means if you're play a First Person Shoot, you can pay $0.99 (or whatever they choose) to get yourself a better gun.)
• Peer-to-Peer connectivity, which should allow multi-user, or multi-player interaction for games or information exchange using Bonjour and Bluetooth (no pairing needed).
• Push Notification Service, which was first announced at WWDC last year, will finally make an appearance and allow developers, through Apple's server, to trigger badges (like Mail's unread message counter), custom sounds, and modal alerts (like the new SMS message box).
• Maps lets developers embed Google Maps functionality in their own applications with full interactions, but also custom annotations.
• Accessory support means developers can now interact with "made for iPod" certified accessories either via Dock port or Bluetooth -- no word yet on Bluetooth keyboards, however.
• iPod Library access -- which we're sure Steve Jobs wrestled from Big Music's petrified hands -- let's developers access onboard audio content, so users can listen to their own stuff, in 3rd party apps.

There's a lot more to it, of course, especially at the deeper and more fundamental levels it looks like. Hopefully if Apple can get the App Store sorted out in similar fashion, iPhone Apps could be steamrolling into the second generation!

Our sibling-site PreCentral.net points us to an interesting developer commentary up on Ars Technica which provides this little golden spitball of insight:

he had a lot of good things to say about how Palm is handing the extremely nascent developer community and his hopes for the future of the platform. The developer told us that he has explored mobile development on Apple's iPhone SDK and found much of the company's position towards their community to be "developer-hostile"—an obvious reference to their insistence on enforcing a pointless NDA well past its expiration date and their strong hand in regulating what can and cannot be developed for its platform.

Apple, of course, is providing Cocoa Touch, an iPhone-optimized version of their Objective C frameworks that, while highly administrated by Apple, provides desktop-class power with a hefty of amount of access to developers. Palm, by contrast, is using Mojo as an open, web-standards based framework for the webOS, which we're guessing will be something similar to how Widgets work (half way between WebApps and native apps).

Every solution comes with compromises, so in the end it will be up to each developer to choose which platform(s) best suit their needs and the apps they want to build, but is the way in which Apple treats developers -- something entirely outside the SDK -- going to be a concern as competing alternatives like Android and webOS become increasingly available?

As revealed by Craig Hockenberry on Twitter shortly after today's iPhone OS 2.2.1 update: developers hadn't heard a whisper of this release, no beta, not even a warning, and it wasn't compatible with the previous SDK. Nice, Apple!

It should come as some relief, then, that the iPhone SDK has now also been bumped to 2.2.1. Says Ars Technica's Erica Sadun:

In all likelihood, the 2.2.1 SDK is, as suggested, a simple bug update without any significant API changes.

So not much different from the iPhone OS 2.2.1 then?

Of course, with such a minor point release we can't really expect anything revolutionary (we'll likely need 3.0 for that). But Apple has been known to sneak some early clues into frameworks, so hopefully we'll find something to look forward to once the deep code divers get through tearing this one apart.

iPhone developer extraordinaire Erica Sadun over at Ars reveals that Apple has expanded on the iPhone SDK samples, and with some pretty nifty new stuff.

While I can't claim to understand it, included in the update is aurioTouch and oalTouch for scilloscope and positional audio, Accessory and TouchCells which (apparently!) give greater options in tables and cells, and URLCache and Reflection which focus on Web-based data and image reflections respectively.

Says Sadun:

The iPhone Reference Library is an amazing resource for developers. It offers access to sample code, guides, and release notes. The new items I listed here augment Apple's already rich iPhone sample code suite. Make a habit of stopping by the library page; Apple will often add new items there without announcement.

Check it out!

Beta release 8 is compatible with the final iPhone OS 2.0 release and must be used to build and sign any iPhone OS application to be submitted to the App Store. As a reminder, you must be a member of the iPhone Developer Program to submit apps.

So quoth Apple's developer site, continuing its relentless schedule leading up to a rumored Friday Gold Master, and a necessary July 11th iPhone 3G launch.

The latest beta weighs in at 1.25 GB and is identified as 5a345.

What's new this time around? Aside from stability, new certificates replaced the previous, just-expired certificates. Only time and the usually bit-by-bit code inspection will tell what else may lurk in the strings (like MMS and Secure Erase?).

However the SDK beta does require the also available-to-developers beta of iTunes 7.7, with a new, fresh tab to handle App Store apps the same way its previously handled Music, Video, and the rest of your iPhone content.

We're through the looking glass, folks.

Read

This is the month we are supposed to see the unveiling of the iPhone SDK, finally ending all the omgnoappz drama and obviating the need for Jailbreaking for all but the most hardcore of iPhone users. It feels like the wait has taken forever.

Now we see that TUAW is reporting that there will indeed be an Apple event at the end of February. Many are hoping that it will be the release (or at least more details) on the iPhone SDK. Others are hoping for a 3G iPhone announcement -- but that seems much less likely given that Apple just released the 16GB model.

So let's join the bandwagon and assume it'll be an SDK event. Cool. Now the real question, the one that put an icy lump of fear and doubt into our hearts during the last Phone different podcast: what if it's just an announcement of an SDK for developers, that Apple won't let the apps on for another 6 months?