Apple has officially released the new software development kit for iPhone OS 3.2, which enables third party developers to begin creating new apps that take advantage of new features of the iPad.

Existing members of Apple's iPhone Developer Program can login and download the new SDK, which includes an iPad simulator for testing new apps under development.

The site also presents an iPad Programming Guide that "introduces new features available for iPad and how to implement those features in your applications," as well as new iPad Human Interface Guidelines.

Apple says the new user interface guidelines outline "how to effectively use the new views and controls available to you to deliver unforgettable applications to your customers."

The SDK also includes new example code projects that "provide an example of how to accomplish a task for a specific technology."

Apple is also launching a new Universal Application binary format for iPhone OS apps that allows developers to deliver a single app that can take full advantage of the features of the iPhone, iPod touch, and iPad. This essentially wraps iPhone and iPad code into the same app package for easy distribution and management.

Apple is also launching a new Universal Application binary format for iPhone OS apps that allows developers to deliver a single app that can take full advantage of the features of the iPhone, iPod touch, and iPad. This essentially wraps iPhone and iPad code into the same app package for easy distribution and management.

Good luck with that. I can see iPhone apps scaling up for the iPad, but I expect the better made iPad apps to not be transferable to the iPhone.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

Good luck with that. I can see iPhone apps scaling up for the iPad, but I expect the better made iPad apps to not be transferable to the iPhone.

I think they mean to wrap both versions of the app into one wrapper, not expect the app to work on both platforms unchanged.

I'd bet that this is the case with all the Apple iPad apps. I don't see them writing a mail client for each device, nor is it a good strategy to take.

Eventually, the ideal would seem to be two streams, OS-X "desktop" and OS-X "mobile." You would want the OS-X mobile apps to work on any and all mobile devices (irrespective of screen size and other things), and to reconfigure themselves depending on the device they are running on. So Facebook's app is just Facebook's app and it reconfigures itself for the iPad when it's running on one, spreading out to include more real estate, features etc. Same with all the others.

Good luck with that. I can see iPhone apps scaling up for the iPad, but I expect the better made iPad apps to not be transferable to the iPhone.

There probably doesn't have to be feature parity between the two versions. Developers could make iPad apps with simplified iPhone versions as a bonus to those who have both devices. I do hope they allow developers to charge separately for iPad and iPhone versions though, or we might see less work put into optimizing apps for each device.

I'm surprised they even used the Universal Binary name, since the iPad and iPhone have the same processor architecture. Porting between platforms might be as simple as tweaking the interface and making the best of the available processor speed.

Any developer will tell you that creating the 'view' is the easy part. the model/viewmodel is where the real meat of it all is. So its smart just to create a single binary and adjust as needed. Cake really. Apple provides all the features you need for gathering input and displaying what you need so it's just the backend that is the real banana.

For you may be. But for developer it is exciting. The first beta release was not complete and you could not do much with porting your existing iPhone app. This release is actually much better. I can now start working on universal binary for my App and have it ready for the final release.

I'm surprised they even used the Universal Binary name, since the iPad and iPhone have the same processor architecture. Porting between platforms might be as simple as tweaking the interface and making the best of the available processor speed.

That is my biggest problem with it. Universal code for the Mac compiled the very small amount of code for PPC and Intel, but Universal in this sense will different layouts but the same processor type. That is a lot of extra code unless Apple got very clever. I'd like iPhone apps that can run on the iPad and iPad apps that don't run on the iPhone, if they can put both into one package to help sell the iPad I'm okay with that, but if it's a "write once run everywhere" design I am not how well that will go.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

Good luck with that. I can see iPhone apps scaling up for the iPad, but I expect the better made iPad apps to not be transferable to the iPhone.

Developers can either create new version of their iPhone app from scratch or a universal binary that can run on both version. For apps that uses navigations it is easy to create universal binary. However, I can see many cases where it is not a goo idea. For example, a word processing or a spreadsheet app will need to be done using new project file.

There's a couple by Microsoft in the App Store:
[...]
The likely success of the iPad will bring more...

Since MS doesn't have a true competitor to the iPad and since this will likely find a lot of use in a business setting I would expect that they are running the numbers for creating a version of MS Office for the iPad.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

I'd like iPhone apps that can run on the iPad and iPad apps that don't run on the iPhone, if they can put both into one package to help sell the iPad I'm okay with that, but if it's a "write once run everywhere" design I am not how well that will go.

There are some difficulties with it. I imagine we'll have 4 classes of apps
1) iPhone apps (which the iPad can run)
2) iPhone apps with minor interface tweak for iPad (developer makes it look a bit better)
3) iPhone/iPad apps where the iPad interface is significantly different.
4) iPad apps which are just not practical on the iPhone.

I play Chess with Friends - I imagine they'll make a better looking interface for the iPad... roughly falling into #2 above. I use the Pocket Weather app - I can see them integrating weather radar into the iPad screen (instead of a link to it), and possibly tides too... probably falls into #3.

I agree with whoever said developers might need to charge differently for an iPad version to encourage them to customise the interface - and that would be a pity if I had to buy a separate iPad and iPhone version. Is there a way to get around this (could a "premium iPad interface" be an in-app purchase?)?

I just hope developers don't get "lazy" and not support all four display configurations-- landscape/portrait, iPad/iPhone. Some of the apps I use have half-implemented ladscape designs where you can't do anything until reorienting to portrait.

I know it complicates things, but it really is an all-or-nothing thing sometimes.

Any developer will tell you that creating the 'view' is the easy part. the model/viewmodel is where the real meat of it all is. So its smart just to create a single binary and adjust as needed. Cake really. Apple provides all the features you need for gathering input and displaying what you need so it's just the backend that is the real banana.

Unless you're developing for the iPhone. Then the view is everything and the business logic is generally trivial by comparison.

Good luck with that. I can see iPhone apps scaling up for the iPad, but I expect the better made iPad apps to not be transferable to the iPhone.

Probably in some cases you are right but I can imagine that a lot of developers will deliver one app and have different views customized to different devices on the platform. Especially if for a while the iPhone is very dominant in install-base, which it should be.

It's also pretty cool that you might buy an app once and then get two experiences from it depending on the device you use. Developers need not support this but it is cool that they have the option.

Any developer will tell you that creating the 'view' is the easy part. the model/viewmodel is where the real meat of it all is. So its smart just to create a single binary and adjust as needed. Cake really. Apple provides all the features you need for gathering input and displaying what you need so it's just the backend that is the real banana.

Many people do. Personally, I am all Mac at home and work and happily finally uninstalled Office some time ago. If you are a Mac user, iWork integrates very easily with the iLife apps and shares many of the same editing menus (eg, for altering images) so the learning curve is low and the work-flow is fast.

Also, anybody who gives presentations will likely never use PP again after using Keynote if they can help it; it really is that much better.

One reason I think is behind Apple releasing iWork for the iPad, though, is also to show what the device is really capable of. iWork is a fairly major app suite, and to port it to the iPad must have been an undertaking; they would really have had to think through the interaction the user would need to use the app effectively. This will give lots of developers (especially beginning ones with that greatest of all ideas) a starting point and some motivation.

Your = the possessive of you, as in, "Your name is Tom, right?" or "What is your name?"

You're = a contraction of YOU + ARE as in, "You are right" --> "You're right."

Any developer will tell you that creating the 'view' is the easy part. the model/viewmodel is where the real meat of it all is. So its smart just to create a single binary and adjust as needed. Cake really. Apple provides all the features you need for gathering input and displaying what you need so it's just the backend that is the real banana.

Is this the same method that Android uses for their various devices? Is this how "fragmentation" will be handled for various platforms running mobile OSs in general?

How many Iphone developers (in percent) do you think will develop for the iPad?

If it is easy, damn near 100%. But I would expect the garbage apps to look horrible on the big screen.

It will be very interesting to see what becomes of the mildly amusing garbage apps. I would think that folks will not download "fart apps"
for their iPad nearly as often as for their iPhone. Many of those sort s of apps are for showing off the iPhone in a casual setting. But will folks download them for a device that resides in their living room? I would think that there would be less opportunity for "hey - look at this!' with the iPad.