Most of the info I have found is from a single source, the iPhone Buyers Analysis – a rather pretty single page PDF by a US market research group. Given that Apple are holding their own sales data close to their chest, I’ve had to be more creative in my demographics gathering.

Some claims I’ve seen during my Googling include:

• Women will “upgrade” to iPhone (they’re rich and it’s pretty!),
• Approximately 60% of iPhoners are overweight,
• 60% of business users are considering an iPhone,
• 1 in 4 Japanese users want an iPhone – despite 59% of those asked not knowing what it was.

I think this goes on to prove the old Homer Simpson quote: “Oh, people can come up with statistics to prove anything. 14% of people know that.”

But the summary is, if you’re a rich, college-educated, current iPod owner, slightly overweight, in either California or New York and you don’t like your current telco, you are a potential iPhone owner! Yay! That doesn’t help me in the slightest!

Apparently, bills for iPhone customers are huge. Really huge. Amazingly huge… I think you get the idea. AT&T seem to think that listing every single data connection for your account is necessary. And on an account with unlimited data usage, there are a lot of connections!

The first bill for a writer at Ars Technica (who are clearly representative of normal everyday iPhone users *cough*) recieved a 52 page (double-sided) bill in the mail…

Perhaps this could be a new iPhone application I could create – if AT&T (the official iPhone telco) made the bill data available online, it could be turned into an application which could easily navigate the data using multitouch

Also, what kind of a company creates an four-letter acronym (GPRR) to represent a four-letter acronym (GPRS)!

Constraints

Network

Given the limitations (currently) of writing a native iPhone application, the application would be slower/less capable than if it could run natively on the hardware.

The largest problem would be the speed and reliability of the mobile network. Given the 1G iPhone’s lack of high-speed data transfer (EDGE doesn’t really cut it) the app may well be painfully slow to use. This would really affect the usability of the application and limit it to nothing more than emergency editing (i.e. you can’t use anything else). I think this would be a problem over any sort of mobile wireless access (Wifi is fine, but it’s still a LAN) since those networks have both relatively low bandwidth and rather high latency. Wether the application would still be responsive enough to be “usable” would be quite a challenge.

But for the moment, I’ll assume a 3G or 3.5G iPhone will come out for our ‘lil Southern Land – even so, the issue of 3.xG network coverage will be important.

Currently on my 3G Nokia, I find 3G deadspots in many places around Sydney, including:

• The rail network
  • The City Circle – no mobile coverage at all
  • The Airport Line – GSM voice/SMS only. No 3G coverage
  • East Hills Line – patchy voice reception. Presumably data reception is also limited.
• The CBD – there are alot of mobile blackspots in the inner city. Given that this is a likely area of use for any mobile technology it’s definately a pain.

Probably the best way to combat this would be an offline application (again, forcing it to run natively) which can upload content via the network when it becomes available – ideally, it can do this in the background.

Interface

The interface really makes or breaks any mobile app. Most cellphones have really crappy interfaces hiding really useful options below a set of nested menus.

Trying to create a compelling and easily usable interface is certanly a challenge on a mobile platform. To compound things, creating this application to run on any capible phone would drastically increase the potential market. But, the downside is that you then have loads of possible input devices and screen-resolutions etc…

On the upside!

There are a bunch of reasons why this at least would be theoretically possible. Technologies like:

• Publicly accessible APIs for web sites like Flickr mean a third-party application can post images to a users account.
• Server-side applications like Adobe Flex or the opensource GD/ImageMagick allow photos to be edited on a server environment.

Steps

Ignoring all of the problems I’ve thought of… here is a rough list of what a person would do to use the application.

1. User takes photo
2. User loads application
3. User uploads their photo(s)
4. Can be automatically set to default and uploaded to their website/blog
   OR
   • The user can crop and rotate the image
   • The user can choose to auto adjust colour and brightness (autofix) or manually adjust the image.
5. The image can be rescaled to new dimensions ready to be posted.

It’s nothing more than a simple “Hello World!” application, but since they have already reverse engineered the iPhone’s API someone can make an nice app – and hope Apple doesn’t sue them for doing so

To get going:

• You can’t install software natively on the iPhone (unless you are Apple), everything (as far as I can tell thus far) is a Web 2.0 application. Whether there will be any offline support for when your iPhone is out of an area with data coverage is something I need to find out.
• The iPhone doesn’t support file uploads so I’m wondering if there is any way to upload photos made using the iPhones camera (I have to investigate if you can send them as e-mail attachments). If it doesn’t it becomes seriously limited…
• No multimedia messages (MMS). Again, for a camera equipped smartphone it seems like a pretty huge omission.
• It’s extensibility is possibly pretty limited by the fact you can only create applications through Javascript/XHTML (JS is powerful, but it works within the limitations of the browser)
• Will 3rd party addons become available for the iPhone given the limitions on appl9ication development.
• Apple decided to have no support for Adobe Flash – given that most other devices have a Flash client available.
• No Java – although I don’t think this is much of a problem, but given the ubiquity of mobile Java applications (i.e. cellphone games, Opera Mini and such) it seems a little strange. Then again, Apple and Sun don’t seem to have a particularly cozy relationship [actually Sun doesn't seem to like anyone...]).

But as Rob has said, given the rumours that Apple will eventually release an iPhone SDK it’s possible to justify our applications as running natively on the iPhone.

First up though, some of the cool features of the iPhone that I like:

• Built in 802.11B/G wi-fi
  • Allows data to be pulled over a WLAN instead of over the more expensive mobile/cellphone network
• Multitouch interface
  • Pure shiny Apple here, if it really works as well as expected it should make interacting with cellphones much easier
• Hi-res (320×480) screen
  • For comparison the Nokia N95 has a 320×240 screen. The iPhone resolution is higher than many Windows PocketPCs
• Safari
  • A mobile browser with desktop levels of support for web-standards like XML, CSS and Javascript. It also supports some of the mobile web-standards for backwards compatibility.
• Multimedia support
  • It supports a whole load of multimedia formats (MP3, MP4, QuickTime, H.264 etc)
• Very shiny design
  • It’s interface is usual Apple shinyness and;
  • It’s physical design is rather attractive too.

The iPhone cons are available over here.