iPhone SDK – Favorite question in the press Q and A – Apps easy to get on the iPhone

CHiPsI was very pleased by a question in today’s press Q&A at Apple’s iPhone SDK release announcement. I posted the other day about the iPhone SDK being in development since before WWDC ’07. The question pertained directly to my thoughts, “Why did you change your mind about the iPhone open SDK? How long will apps be vetted before being published?” (actually, two questions).

Steve answered, “We change our minds a lot. The web apps have worked well, but developers wanted to do more. And we heard that. Creating an SDK is a lot of work, you want to make it something you can live with for 20 years, and yet update it without breaking apps. This is an elegant and clean system.”

I’m certain Apple had the SDK in development since before WWDC ’07. As Steve said, it takes a long time to develop an SDK. They just weren’t ready to announce it yet last year and covered by offering web apps. Their marketing machine and product release practices entice us to want more. We hated Apple last summer for it!

The remainder of the question was handled by Phil, “Second question. Electronic submission will be very fast, and this is a whole new process.”

A lot of people are screaming bloody murder about Apple controlling this process. While I don’t really like the idea of only getting Apps installed via Apple’s system, it could be a lot worse. Apple will be CHiPs, not the DMV. There will undoubtably be apps which make it possible to download and install while being untethered anyway.

The impression I got during the sign-up process to develop for the iPhone and download the SDK was impressive. Not because of the smoothness of the process (I hit terrible snags due to the server congestion), but because it’s obvious they’re going to allow developers to easily publish apps. What I got out of it is they’re making it better and easier to write software for the iPhone than for Windows Mobile or other handhelds. Apps will be as easy to publish as an album of music… Same model.

Dave Winer has been leaning towards the negative side of Apple’s plans, but he likes the idea of an untethered podcatcher. I’d love to talk to him about that… It’s something I expect iofy to work on.

iPhone SDK released – Apple’s iPhone developer site drops connections

developer.apple.com down

Above screenshot taken from http://developer.apple.com/

The iPhone SDK was released today as predicted. Either there were errors in Apple’s push of the site updates or, more likely, developers are so hungry for this SDK that developer.apple.com is down.

I’ve been hammering on ‘Refresh’ for an hour. Could everyone please stop so I can get started on some code!?

The Mac/PC dev/QA environment

 Mac/PC Dev Environment

Developing PC applications on the Mac is great, contrary to what some believe. I too was once in the ‘build-on-the-platform-you-target’ camp. Forget that horse-puckie and get efficient:

  1. Get VMware Fusion: http://www.vmware.com/products/fusion/.
  2. Make sure you’ve got XCode. This will be sixty percent of your development environment and you’ll be coding in OS X.
  3. Install Windows XP or Vista, your choice, as a new VM in Fusion. This will be the other forty percent of your development environment where you’ll step code and delve out builds. Don’t set it up with more than 40% of your Mac’s RAM assigned (preferably 25%).
  4. Install your development tools on this Windows instance, probably .NET 2005.
  5. Set up a shared folder for your source code between your Mac user folder and the dev VM. Make it read-write by both systems (a setting in Fusion).
  6. Set up more VMs in Fusion. These are your Test VMs (smaller, fast Windows instances used as QA machines) – as of this writing you should make XP Home, XP Pro, Vista Home, and Vista Ultimate VMs. You may want additional setups depending on your apps needs (administrator settings, etc). Set these up with 25% or less of your available RAM.
  7. Do nothing… I’m waiting for you to finish step 6… It takes a while.
  8. Run Windows Update (if desired) and take Snapshots of each VM (Command+T) after they’re set up. These Snapshots will let you revert to a clean state any time you wish.

Great, now you’re hooked up and can get your code on. With XCode you can utilize all your monitors (if you’re a developer using less than 2 monitors, we need to talk…). You’ll have XCode running with your source code all over the place organized how you like it. You’ll have your development VM running in a corner.

Use XCode as the code editor (you’ve got your source files saved on the Mac, in the shared folder). Keep the development VM running and hit Control+B in it (or better yet, add an AppleScript to XCode to pass Control+B to the VM) when you need a new build. You can step through the code when you need to.

When you’re ready to test your app(s) on all flavors of Windows, launch up the various VMs and install the app(s). Afterwards, restore to the Snapshot you took before. You’re starting from a nice clean start every time.