iPhone SDK posts

A few months ago Macworld asked where's the iPad's Dvorak keyboard? Well, in the iPhone SDK 3.2 Beta 5, which was released on Tuesday, there's support for hardware Dvorak keyboards in the OS; however, still no sign of a soft keyboard layout for Dvorak fans.

A source sent us the above screen shot from the iPad simulator, showing Dvorak layouts as a hardware choice -- and if you've seen a Bluetooth Dvorak keyboard lately, let us know. This setting would presumably allow you to use a standard keyboard with the Dvorak layout, however, and apply stickers to the keys if needed.

Apple's official tech specs for the iPad still only list keyboard support for the following: English (U.S.), English (UK), French (France, Canada), German, Japanese (QWERTY), Dutch, Flemish, Spanish, Italian, Simplified Chinese (Handwriting and Pinyin), Russian.

As Wikipedia states, on a Dvorak keyboard, the letters and frequently-occurring punctuation are organized the letters and frequently-occurring punctuation "so that the cumulative distance traveled by the 10 fingers when touch-typing typical English text is closer to the minimum than when touch-typing that same text via the dominant QWERTY layout. This reduction in distance traveled was originally purported to permit faster rates of typing, but in later years is also purported to reduce repetitive-strain injuries, including carpal tunnel syndrome." The Dvorak keyboard was patented in 1936 by August Dvorak.

[Update: In the original post I used the explanation of a Dvorak keyboard from Wikipedia. While I did originally link directly to the Wikipedia article in the paragraph, I failed to explicitly state or use quotations that I had done so. I apologize for any confusion that this caused and thank the readers who pointed my error out. The error was mine and mine alone.]

TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature.

A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity.

A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions.

#! /bin/bash

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

codesign -f -s "iPhone Developer" $1

There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated.

Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it.

You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign.

Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time.

Please note the following caveats:

• I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application).
• When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail.
• This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here.
• To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.

Are you doing production work and beta work at the same time? Need to install more than one SDK at once? If you've downloaded the 3.1.3 SDK and need to install it on the same system as the 3.2 beta SDK, you'll want to use the Xcode installer's destination chooser.

When given the option of where to install, click on the Developer folder to reveal the pop-up shown here to the right. To create a new folder/location choose "Other..." and use the standard file browser to create and select that location.

I personally use a named folder for all beta installs. My 3.2 beta is located in /Developer32 and I used the standard /Developer path for my 3.1.3 SDK update. Both SDKs coexist in peace with each other, although I did have to assign separate key macros (I'm a Quickeys addict) for normal Xcode and Interface Builder (in /Developer/Applications) and the beta versions of the same (in /Developer32/Applications for me). Having both SDKs available and separate will help you make sure you can test and code in both environments quickly and easily.

Time to update your iPhone SDK to 3.1.3! It's a required update, otherwise Xcode will not recognize or work with your 3.1.3 device. Head on over to the iPhone dev center (developer credentials needed to log in) to download the latest version.

As always, the iPhone SDK includes Xcode, the iPhone simulator, and other tools for developing applications for iPhone and iPod touch. If you want to develop for the iPad, you'll need to join the $99/year developer program and download the 3.2 SDK instead.

Rumors are hitting the ground hard and strong about exactly what to expect in the upcoming (yeah, yeah, possibly mythical) Apple tablet device. And the most important of those rumors, the fact most consistently cited, is the introduction of extra pixels. You might roll your eyes and say, "of course a tablet means more pixels," but what exactly does that extra resolution mean to you as a developer? After all, we don't know what the pixel count will be or whether the (possibly mythical) tablet will offer widget-mode applications using the current iPhone resolution size or full-screen options. So let's look at some of the challenges having extra screen space might offer up developers.

When it comes to the iPhone, Augmented Reality refers to applications that integrate live camera feeds with data generated either directly from those camera images or from related data linked to the user's real world location. Over the past year, we've seen a number of augmented reality applications appear on App Store and in the Cydia store, offering a way to connect real world visuals with enhanced data presentations.

On the recent Augmented Reality front, Sudoku Grab [iTunes Link] developer Chris Greening has been inspired by Apple's recent decision to allow calls to UIGetScreenImage(), the computer function that allows iPhone developers to copy an image directly from the iPhone screen. By relenting on this issue, Apple has allowed programmers to pull live data from the iPhone camera, and process that data in real time. That opens the door to immediate image processing and visual presentation of data on top of that image stream.

The above video demonstrates this ability by scanning for Sudoku boards. When it detects one, the numbers in question turn green. So how useful in general is this new SDK feature? Chris says, "It's a bit horrible to do anything really useful, you haven't got a direct feed from the camera so you have to do a bit of jiggery pokery if you want to draw on top of the camera preview and still have something usable." As you can tell from the video, his "jiggery pokery" is pretty well done. His real time scanning and enhancement of raw image data allows his detection routine to work with the camera's live feed to acquire new Sudoku boards.

It's still early days on the augmented reality front. Greening's work represents just the start of where this technology can go. With faster processors and better screen access routines (UIGetScreenImage is a very slow call compared to the iPhone's non-public CoreSurface routines), real world integration is just going to get better and better.

Apple makes it clear: when applications rely on network connectivity, they must always test for a valid connection and report those results to the user. If the app cannot reach the Internet, the user needs to know. App Store reviewers regularly reject applications that do not test, and when a connection is not found, report that the network cannot be accessed.

Developers need to integrate this process into their apps. If your app connects to a server, for example, it must test the current iPhone configuration and report to the user whenever the network cannot be reached. Apple provides sample code to help with this.

iPhone developer Andrew Donoho was not particularly impressed by Apple's sample reachability code. So he decided to do something about it. He has created an open source, BSD-licensed update, which he posted on his website. His updated reachability utilities fix a few Apple misspellings and tunes up the code, allowing you to revert to the original implementation via compiler flags.

You can easily download his update and integrate it into your iPhone applications. His write-up describes the testing process and offers an implementation process for successive network tests. You build your decision tree and user feedback off the results of each test. Donoho has provided this code to allow others to build off his work without having to re-invent the entire process from Apple's original source.

If you're interested in a slightly different take on reachability, you might also want to take a peek at my UIDevice Extension category, which provides a number of other approaches to Reachability checks. Among other features, the category includes a WiFi check and hooks that allow you to change reachability status from within your application. As noted in the code, these Airplane Mode hooks are for testing only and not App Store safe.

Just a quick heads-up on the flood of tips in our inbox this morning: Beta 4 of the iPhone 3.0 SDK is available now, along with a preliminary build of iTunes 8.2.

New features noted by readers include support for additional over-the-air PIM synchronization sources (including Google and Yahoo in iTunes, per Joachim), copy and paste in Calculator, continued tethering support, and a basic UI for managing an iTunes store account. Update: reports coming in that Notes syncing requires Mac OS X 10.5.7, yet another broad hint that the OS revision is due momentarily.

Thanks to everyone who sent this in.

If you lost out on the chance to attend WWDC 2008 and your development focus is the iPhone, you're in luck. iPhoneDevCamp 2 is scheduled for August 1 - 3, 2008 at the Adobe offices in San Francisco. A follow-up to the first iPhoneDevCamp held in early July of 2007, iPhoneDevCamp 2 is a non-profit event dedicated solely to development of applications for iPhone and iPod Touch using the native SDK and web standards.

As an attendee, you'll work with other developers to create new iPhone/iPod Touch apps, learn how to migrate Mac apps to the Apple handheld platform, and find out how to test and optimize your apps. If you're a Cocoa Touch developer, web developer, UI designer, or tester, this is the place to be the first weekend of August. The registration links aren't yet up and running, but be sure to bookmark the iPhoneDevCamp 2 site for future reference.

A big TUAW thank you to Raven for the tip!

If you haven't checked out last week's show yet, by all means grab a copy. We were joined by Craig Hockenberry and Gedeon Maheux from Iconfactory, who gave us the lowdown on the history of the company, the origins of Twitterrific, the coevolution of Twitter with the now-dominant Mac client, and the promise of the upcoming iPhone development explosion. Download direct, listen in your browser or subscribe to the TalkShoe feed in iTunes.

Speaking of iPhone... We are live tonight (Sunday 3/9) for this week's talkcast, 10 pm ET, talking about iPhone for enterprise and the SDK -- featuring a taped segment with Erica Sadun and Apollo IM developer Alex Schaefer, who couldn't make the regular Sunday night show but felt they had to say something after 72+ hours deep in the SDK.

Join me, Scott, Dave and Mike Schramm tonight for the social. Bring your own ice cream!

Sometime yesterday afternoon, as soon as her download finished, our friend and colleague turned up her iTunes, closed her office door and tore into the iPhone SDK with all the excitement of a kitten attacking a new skein of yarn. 24 hours, not much sleep and a diet of flat food later, she emerges with her quarry: a shiny new application for iPhone and iPod touch, ToDo App.

This marathon initial effort provides basic todo list features -- adding, listing and deleting. Here's the catch: for now, the only place you can run it is inside the Aspen simulator in Xcode; as soon as Apple starts delivering signing keys to registered and paid developers, those will allow the app to be loaded and tested on physical phones.

In addition to the coding frenzy, Erica found the time to revise her iPhone frameworks documentation and header notes to version 1.2, which reflects the SDK edition. After a long sojourn in the wildnerness of the community toolchain, the iPhone devs can see what appears to be the promised land. Here's to the crazy ones.

Want to get your hack on with the iPhone beta SDK? If you're in Austin, TX, you're in luck. As part of BarCamp in Austin, a bunch of iPhone SDK hackers are putting together an iPhone track tomorrow (Saturday). There will be tutorial sessions, demos and hands-on hacking.

The fun starts at 10AM and goes until 10PM and will be held GSD&M|idea city, 828 West 6th Street in Austin. For more information, contact Bart Decrem of Gogo Apps, an iPhone startup (bartd@gogoapps.com). Confirmed attendees include Daniel "Pumpkin" Peebles, Sean "iAppADay" Heber, Thomas Muldowney, and Layton "Polarbear Farms" Duncan.

Uncle Steve hinted last week that 3rd party software development would be coming on the iPhone sometime in the future. Gruber wondered aloud over at Daring Fireball just where the iPhone SDK might be that would make this possible. Well according to the New York Times, something is coming at WWDC. An anonymous source "briefed on Apple's plans" said that at WWDC, "Apple intends to announce that it will make it possible for developers of small programs written for the Macintosh to easily convert them to run on the iPhone."

Hmm... "small programs"? That sounds a lot like widgets to me. The obvious question is just how limiting that will be. After all some dashboard widgets out now already tie into the Mac pretty deeply. So even if 3rd party devs are limited to widgets it's still likely that quite a lot will be possible. If we're lucky "small" may just refer to the binary size, and full cocoa apps will be allowed as well.