If I were to speculate about what Apple’s big WWDC TBA session is (some have guessed television), I would guess Apple is going to teach its multitude of developers the basics of natural language processing and how exactly it plans to let them integrate with Siri. 

I think Siri is a great guess. Voice commands are extremely useful. The only reason I don't use Siri more is because it's quite limited. It's like the iPhone before the App Store. Sure, Apple's built-in apps are great, but adding the App Store takes it to another level.

Siri is also a great way for Apple to distance itself from the competition. When it was announced in 2007, Steve Jobs claimed that the iPhone had "software that’s at least five years ahead of what’s on any other phone". It's now 2012, Android and Windows Phone have largely closed that gap, and Apple is probably looking for another five year advantage. A version of Siri that could make use of the mountains of information stored in custom apps could be huge.

If this is true, we third party developers have a lot of work ahead of us, and this work can be broken into two parts: Services and Semantics. Services already exist in OS X, Android, and Windows 8. This is the system-wide ability for an app to accept various kinds of tasks from another app. For example, if I develop a new music app, I’ll want to be considered by Siri if the user makes a music request. Thus, I’ll register my app with the “Siri Play Music” Service.

There will be a Siri service for third party developers, but I don't think it will be limited to the phone. The main reason is that many apps fetch information on an "as needed" basis. For example, a sports app won't know the latest scores or schedules until the user launches the app and the scores and schedule are downloaded. That's a problem if the user asks, "When does the Duke game start?". The information to answer the question might not be on the phone.

Another problem is that the iPhone isn't designed to run many apps in parallel. If the Siri needs to launch every Siri-enabled app on the phone to evaluate the user's question, then it could be painfully slow.

My guess is that Apple will allow third party developers to extend Siri at the server level. Here's how it could work:

1. A user asks their phone, "When does the Duke game start?"
2. The phone contacts Apple's servers with the question.
3. Apple's servers figure out which Siri-enabled apps can handle the question. 
4. Apple's servers contact each of the third party servers with the question.
5. The sports app's servers responds with "Duke is playing at 7pm tonight".
6. Apple's servers send the response to the sports app on the phone.
7. Through the Siri interface, the sports app displays "Duke is playing at 7pm tonight" with the Duke logo, and map to the venue. It also instructs Siri to ask the user "Do you want me to add it to your calendar?"

And it could all happen quickly and efficiently. Servers are great at handling parallel operations, and they always have access to the latest information. The iPhone's sports app only needs to provide custom user interface elements to Siri.

Let’s keep in mind that a conversational semantic services API of this kind —whatever it will end up looking like—has never been done before and will likely require new tools, new paradigms, to fully capture its power and breadth. And I can’t think of a better place, or time, to introduce such a platform than at the upcoming WWDC.

Agreed. And if this is the direction Apple is going, then a good number of the TBA sessions might be to introduce a powerful and potentially complex server-side Siri API to thousands of primarily client-side developers. But does it need to be complex?

Let's take it one step further. What if Apple intends to launch a service that will take the pain out of server-side development? Siri integration, push notifications, and iCloud access could all be part of it. Think along the lines of Parse, Urban Airship and Heroku –– a hosting environment to handle the server-side parts of an iOS app. Operated by Apple, it would be based on familiar iOS technologies like Objective-C, ARC, and FoundationKit. This kind of service could benefit a lot of independent iOS developers. And, like the Siri API, Apple could use it to gain another five year advantage over the competition.

Second, an increase in screen size must to be done in a way that maximizes backwards compatibility with existing apps. When Apple introduced the retina screen, they did it by exactly doubling the resolution. The result was that all standard resolution apps still worked. They didn't take advantage of the higher resolution -- but they worked as well as before. Over time, developers could opt-in to support the higher resolution.

How can Apple maintain a great app experience for users while increasing the screen size? All existing iPhone apps have been designed to work on a 640 x 960 screen. John Gruber points out that all apps should be somewhat flexible for height:

But, keep in mind, iPhone apps are already expected to be at least somewhat flexible in height. Use a well-written app while you’re on a phone call or making a recording with the Voice Memos app, and you get a double-height status bar (green for phone calls, red for recordings). But the double-height status bar doesn’t cover the content of most apps.

The problem with this argument is that apps are expected to adjust their size to become slightly smaller, not significantly bigger. Making apps stretch to fill a larger size could expose all sorts of flaws. For example, images that aren't quite big enough to fill a larger screen will show flaws. And Apple doesn't want to see potentially many apps on their flagship iPhone to show flaws.

There is an alternative to stretching apps. Apple can do nothing. By displaying current apps in a 640 x 960 area centred in the rumoured 640 x 1136 screen, apps will behave the same as on an iPhone 4/4S. And over time, developers can opt-in to support the larger screen size by setting a flag in their apps.

TechCrunch:

The SDK requires pretty simple integration. Once wired, users can check-in to apps in much the same manner they check-in to locations on Foursquare. Check-ins can be pushed out, of course, to Facebook and Twitter.

AppBoy included additional functionality that helps developers reward users in contests. Badges are available for most check-ins during a contest, for timing-based check-ins (for example, the 50th check-in past a certain hour), and for checks-ins closest to specified times.

Sounds like a great way to engage users.

TechCrunch:

There’s a saying in hockey: Don’t go to where the puck is, go to where the puck is going to be. Nobody is willing to make a bet on where the market is going to be, so they go to where the market is and, right now, Apple controls the puck.

Until someone decides to step outside of Apple’s shadow, they will never be better than No. 2. That’s where the fight is right now.

It seems HP is in the best position to step outside of Apple's shadow. HP's webOS looks very good and, like Apple, HP controls the hardware and software.

Pinch Media:

For free [iPhone] applications, only about 20 percent of users return to use the app the first day after they download it, and then it quickly drops off from there. By 30 days out, less than 5 percent are using the app. The chart for paid apps shows a slightly steeper fall-off rate. So there is a very brief window of time to capture people’s attention and potential revenues.

I’ll put forth one central, overriding guideline for iPhone UI design:

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.