Finally!

Just received an email from Apple reading

Dear ______________,

Thank you for applying to the iPhone Developer Program.

We have reviewed the information you submitted when you initiated your program enrollment request and we are ready to instruct you on the steps required to complete the enrollment process.

Please click here to review and agree to the Standard License Agreement. You must execute this agreement prior to completing the purchase and activation process for the iPhone Developer Program.

Once you complete and activate your purchase, your enrollment will be complete.

Thank you,

iPhone Developer Program

I have just paid them my $99 (well, $107 + change after taxes), and now what? Don’t they at least need to mail me a certificate to sign my code with? I think I read something about this, going off now to check the developer site.

iPhone SDK beta 5 now available

A fifth beta release of the iPhone SDK is now available at Apple’s iPhone Dev Center. According to the release notes, beta 5 is a bug-fix release. Here’s the recent beta history:

Beta release 5: The fifth beta fixes bugs and adds support for the latest iPhone OS.

Beta release 4: The fourth beta adds support for Open GL ES within the iPhone Simulator, rendering 3D graphics in the Simulator that mirror behavior on the iPhoneand iPod touch. Code signing is now enforced on devices. See the “Known Issues”section below for details.

Beta release 3: The third beta fixes bugs and adds support for the latest iPhone OS.

Beta release 2: New in the second beta release of the iPhone SDK is support for
building iPhone user interfaces using the Interface Builder tool.

iPhone SDK beta 4 now available

Beta 4 of the iPhone SDK has been released:

The fourth beta adds support for Open GL ES within the iPhone Simulator, rendering 3D graphics in the Simulator that mirror behavior on the iPhone and iPod touch. There are new iPhone OS templates in the New Project and New Target assistants. Code signing is now enforced on devices.

The Known Issues section elaborates on code signing:

Code signing is enforced on the device starting with beta 4 of the iPhone SDK and iPhone OS. This means that your project will need to contain a valid certificate signing identity that resolves to a valid certificate in your keychain. If there is no valid identity in the project, the code will continue to function on the Simulator, but will fail to execute on any device.

I’m confused. Didn’t the device always enforce code signing, and fail to execute code built with the previous betas? I couldn’t even get my iPod Touch to load any code, although it’s well possible that’s because I don’t know how loading the Touch is supposed to work. I’m going to keep my eyes open for a better explanation of beta 4’s code signing.

Baby step number two

My application from the Interface Builder tutorial:

iPhone SDK beta 3 now available

Apple has released its 3rd beta of the iPhone SDK. The release notes (PDF) state that

The third beta fixes bugs and adds support for the latest iPhone OS

In addition, the email that announced the new beta release says that Apple has also created

A new tutorial for creating iPhone applications using Interface Builder

That’s something I definitely want to read. Maybe time to buy that new laser printer.

The new SDK is buil 9M2158a, and, like the previous one, it’s about 1.4 GB. I’m downloading it now; even at the relatively fast speed of 750 KB/second, it’s going to take a while.

Baby step number one

I haven’t had a lot of time over the past couple of weeks to do much work on my Touch project. What time I have had, I’ve spent reading up on introductory material, such as Learning Objective C: a Primer from the iPhone DevCenter.

Tonight I decided I’d take a break from the reading and just play around with some code. Download some of Apple’s sample projects and just fool around with them. Change things. See what happens.

I didn’t even get that far.

While I was browsing through the posts at O’Reilly’s Digital Media Mac blog, I came across an interesting post that described two methods of adding a badge to an application icon.

Badges are those red text bubbles that appear over an application’s icon on the home screen. The one I’m most accustomed to seeing is the number of unread messages displayed over the Mail app’s icon.

So I decided to take one of the sample apps I’ve already been working with and see if I can get a badge to display on it. It took a minute of hunting around to find the right place to add the code, but I finally found it. I get a warning from Xcode that the object I’m using might not support the message I’m sending, but it works. You can see the result by clicking the screenshot for a full-size view.

By the way, that error message is something you would never see in C++. In C++, you know for a fact at compile time whether an object supports any given function call or not. Just one little illustration that Objective C’s messages, although they seem like C++ member functions, are not. They’re different. They offer more flexibility, and, I suspect, a whole new category of problems.

New iPhone SDK available

Apple has released a new version of the iPhone SDK, available for download from the iPhone DevCenter. Here’s what the announcement email has to say:

The second beta version of the iPhone SDK is now available and includes Interface Builder, a powerful tool that allows you to visually build your interface and makes creating a UI as simple as drag and drop.

We’ve also added new sample code and updated documentation to the rich set of resources available to you in the iPhone Dev Center.

For more details, see the release notes (PDF).

The new SDK is build 9A2151, and it’s about 1.4 GB. That’s heavy, but not as heavy as the first version, which weighed over 2 GB.

When I saw that I had received an email from Apple Developer Connection, I thought maybe I had finally receive my invitation to join the iPhone beta program. Not my turn to win the Apple lottery, I guess.

Some quick thoughts on app types

Just a quick list I jotted down during a boring meeting, about some applications that would have broad appeal:

• Games
• Internet utilities
• Simulations
• Generic utilities
• Replacements for Apple apps

More about these later.

What kind of Touch app should I build?

Other projects (notably in meatspace — what some of you call First Life) have been keeping me from working with Xcode over most of the last week, but I’ve been thinking a lot about what kind of application(s) I want to make for the iPod Touch/iPhone. The first level of thinking, because I go into this game with no particular itch to scratch, is just what would be the attributes of a successful application? Here’s my thinking so far:

1. Something people will use. Not something just to amuse myself. If other people aren’t also using it, I wouldn’t get a lot a satisfaction out of the project. What I like best is when I make something other people actually use and want.
2. Something that satisfies a need. Not something to write just for the fun of it. It can be a small need that the program addresses, but it should be real.
3. Something people will enjoy. Not just something to fix a problem or fill a need, but a program that’s enjoyable to use. Needless to say, it has to amuse me too
4. (Maybe) something that people will pay for. I don’t pretend that I’m going to get rich writing Touch applications, but it would be nice to sell a few and maybe be able to buy myself an imported beer instead of this domestic swill.
5. Something not too complex. It has to be simple enough for one guy working alone to finish in a few months.
6. Something that limits the amount of new tech I’ll be required to learn. Learning Xcode and Cocoa Touch will be challenge enough without throwing something like OpenGL into the mix too. I need to keep it simple.
7. Something I will enjoy creating. If I don’t have some fun making this application, then what’s the point?

That’s a lot to keep in mind, and realize going into this process that I may not find an application idea that meets all 7 of the criteria I’ve set. The first two seem to be the most important, so I will probably focus on looking for an idea that

• Has broad appeal. Something lots of people can use, something not too specialized.
• Is fun. Easy to use. Pleasing. Pretty.

Stay tuned. More thinking out loud to come.

Insights into developing for the iPhone

Long-time Mac developer Craig Hockenberry wrote a fascinating article back in February, “So you’re going to write an iPhone app…” offering some lessons learned from writing Mobile Twitterific. Here’s the highlights.

On reusing code from Cocoa projects for Mac OS X:

Don’t expect to reuse much of your existing code. If you’re using a standard MVC design (which is pretty much inescapable if you’re using Cocoa) then about 2/3rds of the application will require major rework.

From my experience, your models and the infrastructure that support them can be reused without much effort. On the other hand, the multi-touch interface obviates the need for your existing views and controllers.

This won’t be a problem for me, because I don’t have any existing code, at least not any existing Cocoa code.

On memory:

There are some very tight limits on memory usage. You’re given approximately 64 MB of space to work with (about half of what’s available.) If you go beyond that, Springboard shuts you down unceremoniously. That combined with the fact that there isn’t any swap space where unused objects can go to rest, makes for some design decisions that you haven’t had to consider in the desktop environment.

I think I can live within 64 MB as long as I keep that limitation in mind as I design and write my app.

On UI complexity:

The good news is that the user interface is much less complex. The bad news is that the user interface is much less complex.

If you have a rich desktop application with hundreds of features, you’ll find that it’s hard to pick what you absolutely need. Culling features isn’t easy, but it’s absolutely necessary.

Here again, I don’t have to worry. I won’t have to cull features, because I don’t yet have any. Maybe this is an advantage to starting from scratch for the mobile platform.

On look and feel:

Don’t think that your desktop and mobile application will share any look and feel. There may be slight resemblances with regard to branding, but that’s about it. Does Safari look like MobileSafari?

I might be able to work this problem in reverse: develop the mobile version first, then later make the desktop version. In theory, at least, it should be easier to make a desktop app look like a mobile app (and build from there) than vice versa.

On the simulator:

It’s likely that there will be a simulator in the iPhone SDK. Don’t believe for a second that you’ll be able to use this simulated device for all your development and testing. You have to literally live with the application.

I don’t pretend that I can get by without running on the real hardware. Running on the target is a must for any embedded application. On the other hand, until I get into the commercial iPhone developer program, I’m going to have to get by with the simulator. I hope I get accepted soon, but if I don’t, I’ll just have to live with it. I imagine that I can write most or all of the code using the simulator, but when it comes to testing and wringing out the bugs, I’m going to need real hardware.