Note that the app’s layout hasn’t changed at all – after all, fingers didn’t just reduce in size. The new version (currently with Apple for approval) also brings fast application switching, which is very handy when checking for updates on a delayed train.

Each image below is a link to the high-def version of the image.

Home screen

Live progress

Station search

Journey planner

Check alternatives

Cancellations

On your iPad, visit http://www.bbc.co.uk/iplayer/bigscreen:

Tap the “+” icon, and then tap “Add to Home Screen”:

Give the new home screen icon a name (e.g. “BBC iPlayer”), and then tap “Add”:

You’ll now have an icon on your iPad’s home screen for BBC iPlayer:

Tap the icon to launch iPlayer as a full screen web app:

When you play a video, it displays full-screen with auto-hiding controls:

I saw a comment from a member of the group the other day, shortly after Section 3.3.1 went mainstream:

Could this mean more accessible apps for VO users?

Note the meaning behind the comment.  Not “how dare they”, or “shame on you”, but “hurrah – this will mean that apps are more likely to be accessible via VoiceOver.”

Making better quality iPhone apps isn’t just about how they look – it’s about how they sound.  And that’s another reason to develop your apps in Xcode.

Call A Friend

Here’s how it works. Imagine that a Conservative voter – let’s call him Peter – wants to campaign on behalf of the Conservative Party. He installs their app, and taps the “Call a friend” button. He sees some brief instructions, and taps “Continue”.

Peter then sees a list of everyone in his iPhone’s address book. He decides to call a friend – let’s call him Bob – to talk about the Conservatives. Peter taps on Bob’s name in the list, and sees Bob’s contact details.

Peter taps on Bob’s phone number to call him. They have a nice chat about the Conservatives. Despite Peter’s best efforts, Bob politely indicates that he’s intending to vote for Labour in the upcoming election.

After the call, Peter re-opens the app. He sees a screen with Bob’s name, address and postcode filled in from his address book. He adds any notes from the call, and indicates Bob’s likely voting intention.

Peter then taps “Send email”. The app creates a new email to callafriend@myconservatives.com. Peter sends this email to the Conservatives. Bob’s voting intention is now displayed below his name in the app’s “Call a friend” list.

When I first saw this process, I thought it seemed a little odd. Normally, when you give out your personal details, it’s made clear how these details will be used, with a privacy policy and an opportunity to say “yes, I agree”. I couldn’t see any of this in the Conservative Party app. And in fact, it’s not Peter’s details being submitted – it’s Bob’s. Who doesn’t get a say in it at all. I decided to read up about the Data Protection Act, to find out more. After some reading, I also called the DPA helpline with a few questions.

Processing

The DPA applies whenever someone stores or uses your personal information (the Act calls this “processing“ your data). From what I’ve read, if the Conservative Party are storing Bob’s name, address and voting intention in an email mailbox, or using it to help with local campaigning, then this would count as processing his data, and so the Data Protection Act would apply.

Transparency

The Act requires you to be open, honest and transparent about how you use someone’s personal data. The nearest the app gets is to say that “this data will be used to help with our local campaigning”. I’m not sure that qualifies as “transparent”. Will Bob be getting a letter in the post from his local Conservative candidate to try and change his mind? Will Number 1, High Street, Anytown be getting a personal visit to persuade Bob to vote Conservative?

Moreover, this text is displayed to Peter, not Bob. In fact, the Conservative Party can’t be open and honest with Bob about its intended use of his data, because they don’t ever speak to him. Nonetheless, they may be storing and processing Bob’s personal information in their mailbox. According to the DPA helpline, as recipients of the data, the Conservative Party would have a responsibility to ensure that Bob is notified as to how his data will be used.

Privacy Notices

I decided to investigate this need for notification in more detail. The Act requires you to provide a privacy notice, saying how you intend to use the information you gather. I had a good poke around in the app, but I couldn’t find a privacy notice anywhere within the app. I looked on the websites mentioned on the app’s App Store page, but neither myconservatives.com or conservatives.com had a privacy notice for the app either. I tried the “app support” link on the App Store, but this just took me to the home page of Deluxe Entertainment Services Group. I’ve no idea who they are, but their site didn’t even mention iPhone apps, let alone a privacy notice for the Conservative Party app.

Consent

I read more. In order to process someone’s personal data, you must meet at least one of several conditions. For this app, it looks as though the relevant condition is that Bob has given “consent to the processing”.

However, the app doesn’t ask Bob for his permission at all, let alone check whether he has given his consent. The app doesn’t even ask Peter if consent was given, and doesn’t provide any guidance as to how Peter should approach Bob when he calls. By the looks of it, it is entirely Peter’s choice as to whether he even mentions the fact that Bob’s data will be sent on.

Summary

So what does this all mean?  Well, if my understanding of the DPA is correct:

• It’s possible that personal data is being stored or processed by the Conservative Party, without them having any contact with the person whose data is being processed
• There is no verification that the data is provided with the consent of the person that data refers to
• The app doesn’t give a clear indication of what the data will be used for
• Neither the app nor its supporting web sites contain a privacy notice describing how the data may be stored and used

I should stress that I don’t know if or how the Conservative Party are storing or processing the data from these emails (although I have contacted them to find out, and will post again when I hear back). I would be very grateful if anyone with experience of the Data Protection Act could confirm if my reading of the Act is correct.

Disclosure: I’m not a member of, or affiliated to, any political party or organisation. I’m just bothered about people’s privacy.

UPDATE: 9 April 2010, 5:49pm

The Conservative Party app’s App Store description has been updated to say the following:

When using the “Call A Friend” feature, please confirm that you have the consent of the friend or relative whose details you are passing on to us. The Conservative Party will inform your friend or relative how it obtained his or her details. Information obtained by the Conservative Party from this App will not be used for electronic mailing purposes.

This change went live within the last half an hour.

UPDATE: 9 April 2010, 6:02pm

This updated App Store description is an improvement. However, it’s still not clear how Peter should confirm that he has the consent of the friend or relative. Is he meant to put this information in the “Notes” section of each and every submission? If so, maybe the App Store description could be updated to make this clear.

Aside #1: I wonder if the app itself will be updated, so that anyone who has already downloaded the app will also get a chance to see this message?

Aside #2: The message about not using information for electronic mailing purposes is a bit superfluous, given that Bob’s email address isn’t part of the data gathered.

UPDATE: 9 April 2010, 6:10pm

Re-reading the new App Store text: while this text mentions what the information won’t be used for, it still doesn’t say what it will be used for. Would be good to know.

1. Is there a way to set the accessibility label of a UIAlertView or UIActionSheet button to be something other than the title of the button? For example, we have a button with the UK spelling of “Add to favourites”, but VoiceOver does not pronounce this correctly, so we would like to set the accessibility label to use the US spelling (”Add to favorites”) to ensure that VoiceOver pronounces it correctly. Likewise, is there a way to set the accessibility label of the UIAlertView or UIActionSheet’s title to be something other than the title?

A: Unfortunately, UIAlertView and UIActionSheet don’t make their UIAccessibility model publicly accessible. The only way to achieve this would be to create our own custom modal views, which we’d rather not do. The alternative is to query and modify the view hierarchy of the UIAlertView / UIActionSheet instance, but this is generally a bad idea, as the model might change in the future.

2. Is it possible to get VoiceOver to read out an action after an event has completed?  For example, our app uses a refresh button to reload a list of live train times.  Depending on the current network coverage and network speed, the reload can take several seconds to complete.  We would like to notify the user via VoiceOver once the refresh has finished, to prompt them to re-read the results detail.

A: Because the iPhone OS accessibility model is based on user actions and gestures, it can’t be triggered programmatically. We could use System Audio Services to play a sound, but this would need us to be able to detect if VoiceOver is turned on, which isn’t possible (see 6 below).

3. Is it possible to assign VoiceOver focus to a particular accessibility element when programmatically initialising a viewcontroller?  We are finding that for most of our viewcontrollers, the UINavigationBar’s back button receives the VoiceOver focus as soon as the controller is loaded, presumably because it is the top-left-most UIControl.  It would be more useful for the user if the ViewController’s title had the focus and was read out in full, and / or if we could set the focus to be on a particular user interface element ourselves.

A: For some scenarios, it might be possible to affect this by changing the hierarchy order of the subviews in Interface Builder. In this example, however, the UINavigationBar’s subview hierarchy isn’t something we can modify, and so we can’t change this behaviour.

4. When should an element be given a trait of UIAccessibilityTraitButton, and when should it be given a trait of UIAccessibilityTraitLink?  We have many UITableViewCells with disclosure arrows, each of which take the user to a deeper UIViewController, and it is not clear from the documentation as to whether these should be buttons, links, or should have some other kind of trait.

A: Apple apps seem to use UIAccessibilityTraitButton for tableview rows with detail disclosure arrows. UIAccessibilityTraitLink is really only for elements that behave like a URL link would – such as opening Mobile Safari, or making a phone call.

5. How should UIAccessibilityTraitSummaryElement be used?  Our application restores its previous state when launched, and we would like to give an indication of the restored state.  However, the documentation does not explain how to use this trait to provide information to the user.

A: UIAccessibilityTraitSummaryElement trait is a hint-like trait, rather than a control-type trait (like UIAccessibilityTraitButton). It is most appropriate when you have some changing information that the user should hear right away when the application starts.  For example, the Weather app uses this trait on the small “City and current temperature” control when it starts up.

This works for Weather because this application’s view hierarchy is fairly flat. If you had a summary trait element inside a subview inside a navigation controller hierarchy (i.e. something not at the root level on startup), then VoiceOver might not recognise it at startup.

6. Is it possible to detect whether VoiceOver is activated, in order to make the app behave differently?  Obviously the primary aim is to make the existing interface accessible, but there are occasions where the visual interface is not best suited to VoiceOver accessibility use, and an alternative / simpler interface would be preferable.  Since VoiceOver can only be turned on or off in the Settings app, we could be confident within a given app launch session that VoiceOver was consistently either On or Off, and could respond accordingly.

A: No. (If like us you’d find this useful, do file a request using Apple’s bugreporter system.)

7. Our app uses the word Live (pronounced “liyve”, meaning “real-time”) in several places, but VoiceOver reads this as “liv”, meaning “to live”.  Is there a way to provide an alternative pronunciation in these cases?  Should we just use a phonetic spelling for the accessibility label?

A: Phonetic spelling seems to be the way to go for alternative pronunciation.  You can use the Mac OS “say” command to try out alternate spellings.

8. Is there a way to set the accessibility label of a UIViewController’s title view to be something other than the title of the UIViewController, without having to set a custom view as its UINavigationItem?

A: Same problem as question 1 – unfortunately, the underlying accessibility for the UIViewController isn’t publicly available.

9. Sometimes, when we return a custom view from tableView:viewForHeaderInSection: for a grouped table, we are finding that the custom view’s VoiceOver highlight rectangle is drawn in the top left of the screen, regardless of the actual position of the view when drawn on screen.  This means that the user cannot move their finger over the actual rendered position of the header view on screen in order to read its accessibility info.  The view is read when using the single-finger-swipe-from-left-to-right command to move to the next control in the controls list (and likewise when swiping from right to left to move back), but the rectangle is still drawn at the very top left of the screen.

A: This seems to be a bug. If you see this problem too, please log a bug with Apple using their bugreporter.

The iBookstore

Physical book sales are on the up, with the UK Adult Fiction market growing by 1.2% in 2009. In the same period, Children’s Fiction grew by 8.6%, and only Trade Non Fiction saw a decline in sales.  The economy may have been in decline, but the escapism of a book shows no sign of losing its grip on the UK’s imagination.

Following the success of the iPhone and the App Store, enterprising book publishers are now launching iPhone apps to tie in with their physical book releases. These apps are typically self-contained eBook readers, incorporating the full text of one specific book.

As with any app, Apple takes a hefty cut of the sale – nearly 39% in the UK once VAT is taken into account. And if a publisher wants to protect the book’s content from jailbreakers, they need to create their own DRM system for each app, increasing the complexity of publishing the book on the store.

With the launch of the iPad, and more importantly the iBookstore, Apple will remove the need for these book apps altogether.  Apple will provide a learn-once book reader, and will provide a new store optimised for discovering, exploring and trying out books. The store will provide book samplers, similar to the 30-second song previews in the iTunes Store.

The choice for publishers then becomes simple: develop, package and launch a custom reader app with its own DRM (and make 61%), or submit a book to Apple and get the reader and DRM for free (and still make 61%).  It’s a classic example of Apple’s “build it and they will come” policy for electronic media sales.

Apple already has the infrastructure and DRM system, and it already has the customers.  By making it easy for customers to buy books, Apple makes it easy for publishers to choose iBookstore.  I expect all major publishers to do so in 2010.

Beyond the book

The industry standard format for eBooks is called ePub, and Apple are using ePub on the iBookstore.  ePub is a useful standard, but it does not lend itself to interactivity.  Basing iBookstore on ePub makes it easy for publishers to unlock their archives and launch their latest releases, but it doesn’t enable them to think beyond the traditional book.

An iPad can do so much more than a physical book. Where content lends itself to an enhanced reading experience, or to something that isn’t a book at all, publishers shouldn’t feel obliged to emulate a book-reading experience just because the interface is familiar.

Apple’s “App of the Year” for 2009 was Jamie Oliver’s “20 Minute Meals” – an app that goes so far beyond the traditional recipe book as to be unrecognisable.  The app has been incredibly popular, with over 85% of users awarding it four or five stars on the App Store.  More importantly, the app has raised the bar for app developers to think beyond the book.  (We have a copy of Jamie’s Wired cover on the wall in our office; whenever a client says “we want something like the Jamie app”, we shake our fists and shout “Damn you, Oliver!”)

For certain types of content, it is no longer enough to release a simple eBook on the iBookstore.  Jamie’s app may have taken a team of 30 people several months to create, but it has shown users what to expect on a mobile device when publishers think creatively about their content.  It has also shown that apps can generate a substantial amount of publicity (and money) for authors when done well.

I expect eBooks to fall into two categories in 2010.  The majority will be standard eBooks sold through the iBookstore; but an important minority will be essential apps in their own right.

DRM

You can’t talk about online media sales without considering rights management, and books are no different.  In this respect, Apple has a major advantage over its competitors.

There are two DRM systems currently in use for ePub files:

• Kindle DRM (used by the Amazon Kindle)
• Adobe DRM (used by the Sony Portable Reader, the Barnes & Noble Nook, and several others)

Kindle devices use Amazon’s own bespoke DRM system, which is not licensed to other developers.  Adobe licenses its DRM software to device and software developers, but it has yet to appear on the iPhone. (This may be due to the $75,000 per-year licensing cost for including Adobe DRM in an iPhone app.)  Lexcycle’s Stanza app was supposed to be adding support for Adobe DRM, but since Lexcycle’s acquisition by Amazon, this has been quietly shelved.

Apple has yet to announce its approach to DRM for the iBookstore, but you can bet your life it won’t be based on either Kindle or Adobe DRM.  Apple’s own FairPlay DRM is one of the most trusted DRM systems going. ePub can be used with any DRM system, so Apple can easily add FairPlay on top of ePub for the iBookstore.

This doesn’t stop Apple offering DRM-free books, of course – but it does mean that they have a proven DRM system with which to entice nervous publishers onto their platform.  With iTunes, it took a reliable DRM system to get music publishers on board, and it could be argued that the digital media revolution, spearheaded by iTunes and the iPod, would never have happened without Apple’s initial use of DRM.  Only some years later could they suggest dropping DRM, to the point where all music sold through iTunes is now DRM-free.  If DRM is what it takes to get the publishing industry on board, then Apple are perfectly placed to win over the majority of book publishers, just as they did for music.

Will users be put off by DRM protection on their books?  I don’t think so.  The iPod showed that most users don’t really care about DRM, as long as they can use their media on all of the computers and mobile devices in their household.  If the iBookstore’s DRM means their favourite books are available to buy and read, with no noticeable restrictions on how they read those books, then most users will be perfectly happy.  Apple got the number of devices spot on for iTunes; it will do the same for iBookstore.

iBooks for iPhone

What does this all mean for the iPhone and iPod Touch?  The iPad keynote didn’t mention iBooks for iPhone, but it seems certain that we’ll see some form of store and reader for the smaller form-factor devices too.

The leading bookstore apps on the iPhone are Stanza and Kindle (both owned by Amazon). There’s no way that Apple will allow Amazon to be the leading bookstore on the iPhone and iPod Touch once it has launched iBookstore for the iPad.  Apart from anything else, Apple would be missing a huge established user base, all of who have iTunes accounts.

Although the iPhone’s screen is too small for lengthy book reading, it is ideal for trying out new books during dead time when you’re on the move.  It is perfect for iBookstore book previews – read the first chapter of a book when on the Tube, and then buy the book on your iPad for reading at home.  (It also gives Apple a nice way to sell the benefits of the iPad to its existing users – “Imagine this reading experience on an even bigger screen!”)

I think that the iBookstore and iBooks apps will come pre-installed as part of an iPhone OS update once the iPad is launched.  If Apple are particularly savvy, books purchased in any iBookstore will sync wirelessly to all of your iPhone OS mobile devices using push syncing, meaning you’ll always have all of your books on all of your devices, without even needing to launch an app to sync.  (This is something Amazon’s apps will never be able to do.)

Unlike the Kindle app, the iBookstore won’t be restricted by Apple’s policy on in-app purchases.  Apps such as Kindle aren’t allowed to sell electronic content for in-app consumption without using Apple’s StoreKit (and doing so gives Apple a sizeable cut of every purchase, something Amazon would never sign up to).  Kindle’s only alternative is to bounce the user to a web page in Mobile Safari, get them to make a credit card purchase, and then sync their purchases when they next launch the Kindle app.  This process is clunky and unintuitive, especially when compared to the iBookstore, which will simply ask the user to enter their iTunes password.

Books may end up being cheaper in the Kindle app, but iTunes has shown that within a certain threshold, an easy purchase is more important than a cheap one.  I expect to see Apple wrestle control of iPhone book sales back from Amazon within days of launching the iPad and its corresponding iPhone system update.

(UPDATE: John Gruber of Daring Fireball points out that iBooks will be a downloadable app from the App Store, and not a bundled part of the OS. Whether this means Apple’s app will have to play by the same rules as any other developer’s app remains to be seen. And I should add that iBooks and iBookstore are two parts of the same app.)

Summary

iBookstore will become the place you buy all of your eBooks, simply because it is the easiest and most pleasurable way to do so.  Publishers will choose the iBookstore as their preferred iPhone / iPad store, benefitting themselves and their readers in the process. Books will come with DRM protection, but the majority of users won’t notice, because it doesn’t stop them reading their books. A few publishers will think beyond books, and will create truly innovative and useful apps from their content.

Adobe and Amazon won’t be able to compete, because Apple will control the entire playing field.  The iPhone and iPod Touch will provide an established user base to get people trying books on the move, and to sell the benefits of the iPad as the eBook reader of choice.  Before long, Apple will be the biggest eBook seller in the world.  And users will be happy about it.

It doesn’t have a camera

It’s 9.5″ by 7.5″ wide, and 0.5″ thick. You want to try taking a picture with something that shape?

Besides, you’ve got a camera-shaped iPhone in your pocket.

It doesn’t make phone calls

It’s 9.5″ by 7.5″ wide, and 0.5″ thick. You want to try holding that to you ear?

Besides, you’ve got a phone-shaped iPhone in your pocket.

It’s got a big bevel round the edge

So have books.

Because you hold them in your hand.

It doesn’t support Flash

Because Flash is slow and cumbersome, and the iPad supports HTML 5.

Name me one web app that couldn’t be achieved in HTML 5, without the need for Flash.

It doesn’t support multitasking

Because it doesn’t need to.

If you really need your apps to multitask when you’re on the move, buy a MacBook. If you’d rather have all-day battery life and guaranteed foreground app performance, buy an iPad.

I already have a Kindle

The base model iPad only costs $10 more than a 9.7″ Kindle DX.

Apparently the Kindle only reads books.

I still feel a bit… underwhelmed

What did you expect – Apple had invented perpetual motion?

Just wait till you use one.

As a developer, this view is fascinating. For example, in the UK app store, the number 1 app by revenue is the £59.99 “TomTom UK and Ireland” app, even though this app only makes number 97 in the Top 100 Paid Apps chart. That’s a huge discrepancy – the 97th best-selling app is currently making more money than any other app in the UK. Compare that to the second-place app by revenue, another turn-by-turn navigation app (CoPilot Live UK and Ireland), which is priced at £25.99. This app is at number 41 in the Paid Apps charts. Continuing down the list, in third place by revenue we have Modern Combat: Sandstorm (£3.99, 5th in the Paid Apps chart), followed by TomTom Western Europe (£79.99, not even in the top 100 Paid Apps), Scrabble (£2.99, 15th) and UNO (£2.99, 16th).

What does this new view tell us?

• None of the top ten highest grossing apps cost 59p (the lowest possible price in the App Store), and all are at least £1.79
• £2.99 or £3.99 games are making substantially more money than 59p chart-toppers
• The Paid Apps chart (which we’ve relied on for App Store statistics for some time now) is not representing the true economics of the App Store
• CoPilot costs less than half the price of the TomTom app, suggesting that CoPilot could and should have charged more
• Established brands (TomTom, GameLoft, EA) can and should charge more for their apps if they want to make money from the App Store – their brand and their quality will result in high-value sales, if not top chart positions

One question remains, however – why have Apple added this view to the App Store at all?  It may be fascinating for developers, but I’m not sure how it helps your average user to choose what to buy, other than saying “Apple makes more money from these apps than from any others”…

The main problem is the lack of a common format between Entourage (.mbox for folders, .eml for individual emails) and Outlook (.pst for everything).  There used to be a really good Applescript export tool for exporting from Entourage, but sadly it’s never been updated to work on Leopard.  You can export a whole folder as an MBOX file from Entourage, but these can’t be opened by Outlook and so aren’t much use either.

(As an aside, there are numerous ways to go the other way, to export from Outlook and import into Entourage.  It’s almost as if lots of people are switching from PC to Mac, but few need to go in the other direction…)

My eventual solution has two parts – getting mail out of Entourage, and then getting it in to Outlook.

Getting mail out of Entourage

For this part, I wrote an Applescript (based heavily on some code from macosxhints.com) to export all currently-selected emails in Entourage to a folder on my Mac.  Many thanks to macosxhints user golgi_body for posting the original code.

Here’s the script I’m using (copy this into Script Editor to use it):

tell application "Microsoft Entourage"

    -- get a reference to all selected messages from entourage
    set selectedMessages to the current messages
    if selectedMessages is {} then
        return
    end if

    -- absolute reference to our export folder
    set fpath to "DiskName:Users:myusername:Documents:existingfolder:"

    repeat with i in selectedMessages

        set sentDate to time sent of i
        set fname to fpath ¬
            & my padNumber(year of sentDate as integer) ¬
            & "-" & my padNumber(month of sentDate as integer) ¬
            & "-" & my padNumber(day of sentDate as integer) ¬
            & "-" & my padNumber(hours of sentDate as integer) ¬
            & "-" & my padNumber(minutes of sentDate as integer) ¬
            & "-" & my padNumber(seconds of sentDate as integer) ¬

        tell application "Finder"
            if (exists file (fname & ".eml")) then
                set k to 1
                repeat while (exists file (fname & "-" & (k as string) & ".eml"))
                    set k to k + 1
                end repeat
                set fname to (fname & "-" & (k as string))
            end if
        end tell

        set fname to fname & ".eml"
        save i in fname
        tell application "Finder" to update file fname

    end repeat

end tell

to padNumber(theNumber)
    if theNumber is less than 10 then
        return "0" & theNumber
    else
        return theNumber
    end if
end padNumber

You’ll need to set fpath to be the path to an existing folder on your Mac. When you run this script in Script Editor, all of the selected files in Entourage will be exported to your export folder as .eml files.

Why use Applescript at all?  Why not just drag the selected emails onto a folder?  After all, this prompts Entourage to export them itself in .eml format.  The problem is, when you do so, Entourage exports the emails using the email subject as the file name.  This can contain all sorts of weird and wonderful characters, and Windows doesn’t like that at all.  This script avoids the problem altogether by using the date and time the email was sent as the filename.  (It also makes it easier to order your .eml files by date and time in the Finder if you need to.)

Getting mail in to Outlook

For this part, I used a Windows utility called Outlook Import Wizard.  It costs $19.95, but it’s more than worth it when you consider the time it can save.  You can download it and try it out for free (max 5 emails per demo import), but be warned – in demo mode, you can’t turn on the “Enable the EML Preprocessing (Unix, MAC)” option to make the wizard recognise Mac-encoded emails, and so your imported emails will contain lots of “=” symbols when you view them in Outlook.  The good news is that the purchased app works fine with Mac-encoded emails.

The import process is pretty easy.  On your PC with Outlook installed, work through the Outlook Import Wizard, being sure to turn on the “Enable the EML Preprocessing (Unix, MAC)” option (found under the “Options” button on the “Select the source folder” screen) to make sure that your Mac-encoded emails are recognised.  The wizard is pretty self-explanatory, and there are full instructions online, so I won’t run through the rest of the settings in detail here.  It’ll take a while to do the import, but eventually you’ll end up with all of your emails in Outlook, with all attachments and the original headers.

I’ve only tried this process myself with Entourage 2008 (on Leopard) and Outlook 2002 (on XP), but I would expect it to work with earlier versions of Entourage too.  The Outlook Import Wizard claims to work on Windows 98/Me/NT 4.0/2000/XP/2003 with Outlook 98/2000/2002/2003/2007, so you should be good to go no matter what your setup.

Phone calls on the iPhone OS are instigated in code by using the tel: schema, as shown below.

UIApplication *app = [UIApplication sharedApplication];
[app openURL:[NSURL URLWithString:@"tel:+44-1234-567890"]];

So on OS 3.0, we use canOpenURL to check if the application can open a sample telephone URL via the tel: schema.

On iPhone OS 2.x, we don’t have canOpenURL, and so we fall back to using the model property of [UIDevice currentDevice] to detect if the device is an iPhone or not. It’s safe to assume that any as-yet-unannounced iPhone OS devices will run OS 3.x or later, and so this provides a future-proofed test for any new devices.

Here’s the complete function I use to perform the check:

- (BOOL)deviceCanMakePhoneCalls
{
    BOOL canMakePhoneCalls;
    if ([UIApplication instancesRespondToSelector:@selector(canOpenURL:)]) {
        // OS 3.0+, so use canOpenURL
        UIApplication *app = [UIApplication sharedApplication];
        canMakePhoneCalls = ([app canOpenURL:[NSURL URLWithString:@"tel:+44-1234-567890"]]);
    } else {
        // OS 2.x, so check for iPhone
        UIDevice *device = [UIDevice currentDevice];
        canMakePhoneCalls = ([device.model isEqualToString:@"iPhone"]);
    }
    return canMakePhoneCalls;
}

This code will compile for any version of the iPhone OS SDK from 2.0 upwards, and has been tested on SDK 3.0. If you compile on an SDK version earlier than 3.0, you may see compilation warnings for the canOpenURL line; these can safely be ignored, as this code will only be triggered when it is run on a device with OS 3.0 or later.