Helicoid's mmm

Getting Started With iPhone Development

This article is republished from Quite Useful (a guide to useful things).

This article is an introduction to iPhone development. You can use it to:

• Decide if iPhone development is right for you
• Understand what skills are required
• Learn about what Apple requires from you and how apps are deployed to phones for testing and the iTunes Store

Is iPhone Development Right For You?

Introductory material to iPhone development makes it look incredibly easy: you just pick components, tie them together with GUI tools, and then run your app and it’s done. This is an illusion: you’ll need object-oriented programming skills as well as some familiarity with Objective-C and Apple’s APIs.

I approached iPhone development with a background in Mac OS development. Here’s an example of my work: Helipad Mac and Helipad iPhone. Therefore I was familiar with Apple’s APIs, Objective-C and Interface Builder. These are the core skills for iPhone development.

When I originally started programming Mac OS applications I found the key to becoming comfortable with development was learning Apple’s Cocoa APIs, and the general Objective-C classes.

Getting Started

To start writing iPhone software, you need to learn the following:

• How to use Apple’s development tools (Xcode, Interface Builder, Instruments)
• Objective-C, which involves everything from object-oriented programming and managing memory
• Apple’s APIs for iPhone and Objective-C development

You also need to sort out a few more mundane details:

• A registered company (note that UK sole traders seem to get on the store)
• Xcode — more about installing Xcode below
• An account at Apple Developer Connection (ADC) — this is free
• The skills to produce logos and supporting graphics, or access to a designer or suitable stock images

It might sound like iPhone development will take a huge investment of time to learn the skills, but you’ll also learn most of the skills you need to write Mac OS software.

From Idea to Deployment

This is the entire process that you’ll go through:

1. [0 days] Sign up to Apple Developer Connection and download the free SDK
2. At this point you can happily build iPhone apps, but you won’t be able to run them on a real phone yet
3. Apply to join the Developer Program (you’ll have to pay $99 and you may need to fax Apple your company’s registration details)
4. [2-14 days] Once Apple accept your application, login to the Developer Program Portal and set up certifications for testing on a real phone
5. At this point you can run your own software on an iPhone
6. Once you’re happy with your application, you can submit it to iTunes Connect
7. You’ll need to set up a contract with Apple in iTunes Connect for free or paid distribution
8. [14-60+ days] Apple will quickly test your application, but it may take them 1-2 months to accept your contracts for selling applications

The last stage of the process can be frustrating: you’re left in the dark for a long time, this was frustrating for me because I didn’t know if there were US/UK contract/tax/banking issues that they were trying to resolve. Then after about 6 weeks my application just appeared on the store (with no fanfare, I found out through a Google Alert that had spidered a site that tracks new iPhone apps).

Xcode Installation and SDK Maintenance

Apple distributes Xcode with Mac OS, so if it’s not in /Developer/Applications you’ll need to get out your Mac OS installation disc. You can even download Xcode from the ADC Member Site (look for the link on the top-right of the developer.apple.com pages). It’s a 1GB disc image, so find your install discs!

The iPhone SDK has an installer so it’s easy to install. Once it’s set up and you’re in Xcode you may occasionally notice that it causes the documentation system to update the API files: these downloads can be huge and will make Xcode sluggish on older or low memory machines.

Objective-C

If you like object-oriented programming (if you’re into Ruby, Java, C#, Python, etc), then you’ll find Objective-C isn’t too painful at all. Don’t worry about learning C from scratch if you’re not familiar with it. If you’re a decent OO programmer, you’ll be able to survive with Apple’s documentation.

If you haven’t done much programming before you’ll need an Objective-C book. I’ve recommended one below.

Apple’s Tools

These are the key tools you’ll be using:

• Xcode - project management, programming, debugging, device management and even source code management (it works well with subversion)
• Interface Builder - drag and drop UI elements and bind them to methods in your code. Not everying can be achieved with IB, definitely not games
• Instruments - Don’t be scared of Objective-C memory management! Instruments helps you track memory, as well as network, CPU and graphics performance

If you’re a programmer who needs to learn C and Objective-C, you’ll find Apple’s rich set of tools and documentation really helps.

Killer Free Resources

• Apple’s documentation (online and within Xcode) will become burned into your eyeballs
• iPhone Developer Blog
• Inside iPhone
• Mobile Orchard
• Theocacoa has some amazing Objective-C/Cocoa tutorials

Recommended Books

I’ve read the following books and they come highly recommended.

Need to learn Objective-C? Get Programming in Objective-C by Stephen G. Kochan.

Want cheap books straight away? Buy some Pragmatic Programmer PDFs and screencasts: iPhone SDK Development, Writing Your First iPhone Application

Helipad iPhone

The Helipad iPhone client has been released on the App Store for £2.99.  It’ll sync all your Helipad documents so you can access them offline on your iPhone.  It syncs both ways so you can add, edit, tag and delete documents from the phone.

Here’s what it looks like in general use:

You can also search documents, which means finding notes when on the move is much faster than the standard Helipad web interface.

During sync a progress screen is displayed.  It will also display any errors encountered due to network issues:

We spent a while testing the sync functionality on different networks: in a big city, out in the countryside and on wifi.  It was very rugged in tests, but if you ever encounter sync issues you can remove all documents from your iPhone and resync.

This is our first iPhone app and we hope to follow it up with Deadline and Tiktrac apps.

Twitter client mobile distribution

Quite a few of the top 100 Twitter clients are mobile:

6. txt

7. TwitterFon (iPhone client)

9. Mobile web

With the popularity of Twitter’s SMS feature and iPhone clients it seems like it’s one of the only social networks to be popular on phones.  However, Facebook has pushed m.facebook.com, and their iPhone client is excellent.

There are stats on Facebook Insider about mobile access.  The iPhone client is currently at #13 on the App Store.  The MySpace client is also apparently very popular.

So with the big social networks clearly popular on mobiles, what’s happening with social networks that specifically target phones?  Last May ReadWriteWeb featured an article on mobile social networks, and it still seems like most of them are in business.  Brightkite has healthy alexa stats.

With Google Latitude and strong mobile support from Twitter, MySpace and Facebook, is there a future for mobile-specific networks?  I think it’s highly likely that developers will focus on clients and supporting services instead, so there will be rich innovation in clients and less alternative networks.  Just take a look at the number of iPhone and Blackberry Twitter clients, not to mention alternative Twitter mobile web clients like dabr and Hahlo.

iPhone dev thoughts

We’ve moved this blog to a new server (it’s hosted at Tumblr now, which cuts down some admin work for us).

Since the last post in 2008 I’ve been doing a lot of work aimed at Blackberry and iPhones.  I’ve also done some iPhone app development (my first app is for Helipad and has been stuck in app store limbo for 6 weeks since submission).

I used to be a C programmer, and trained in C++ at uni.  That means the iPhone’s language and API’s (Objective-C and Cocoa) is relatively comfortable for me to use.  If you haven’t done much C prepare to feel like absolutely everything is way more work than it needs to be.

In fact it reminds me of when I got into Mac programming: Apple were heavily criticised for the lack of documentation on their APIs, so they kept adding more over time, along with great example programs.

iPhone documentation was relatively strong off the bat and continues to get better.  This is great, but the documentation upgrade process in Xcode always makes my computer slow down.

Instruments is a real gem.  I can track down all my memory leaks and other nasty spectres relatively quickly.

Submitting an application isn’t too bad.  Apple’s web interface looks dated and feels awkward, and also times out which can make you have to do the entire thing again.  Woe betide you if you need support, though.  I’ve been waiting since the 17th of December for their “contract processing”.  I had to actually post some sort of US legal crap.  Honestly it’s really more painful than it needs to be.

Getting started with BlackBerry web development

If you’ve created an XHTML Mobile Profile-based site, you might have wondered how well it works on a BlackBerry. Fortunately, RIM provide a BlackBerry simulator, so you don’t even need to own one to test your sites. They also provide an environment that allows you to simulate their web and email services, which ultimately means you can test your sites locally during development (rather than after deployment to a public server.) This environment is called the Mobile Data System, or BlackBerry MDS.

To set up a workable environment:

1. Download the MDS environment and a simulator from here
2. You’ll have to register for BlackBerry’s developer downloads
3. Once you’ve installed both files, run MDS and then the simulator
4. Using the simulator is slightly awkward: treat your mouse’s wheel like the BlackBerry trackball, pressing the wheel in to select items, or use the arrow keys and return. Press F9 instead of clicking the trackball’s button with the mouse
5. You should now be able to connect to web sites in BlackBerry’s browser

There’s a few caveats, however:

• The MDS and the BlackBerry simulators require Windows, which makes life slightly awkward if you’re a Mac or Linux-based developer
• The MDS seems to raise Java exceptions when I connect to websites that use HTTP auth
• To avoid having to switch between the mouse and keyboard for input, keep a close eye on the bottom of the simulator window to see what keyboard shortcuts can be used for the BlackBerry’s buttons

On to web development. RIM provide a PDF that lists BlackBerry support for WML, WAP CSS and XHTML MP: Wireless Handheld Browser Content Developer Guide

A lot is covered in this guide, but you really need to get your sites in the simulator to get a feel for overall support.

BlackBerry’s browser presents a few difficulties when creating XHTML MP sites:

• Table, stylesheet and background images must be turned on in the browser’s options by the user
• Since the browser only supports WAP CSS, you can’t use such esoteric CSS properties as margin and display, rendering most sites slightly messy
• -wap-accesskey and accesskeys in general are ignored

The limitations of the BlackBerry browser are such that you might be left wondering if there’s a conspiracy at RIM to push developers off web services into developing applications that run on their OS, but you can still make workable XHTML MP sites if you’re not too worried branding or anything else that’s typically style-sheet dependent.

Adobe mobile resources

Adobe’s Mobile and Devices Developer Center contains resources for Flash Lite and Device Central, and also features articles about the wider world of mobile development. If you purchased CS3 recently and wondered what use Device Central was, or want to get started with Flash Lite, this is probably a good place to start. Nokia also have Flash lite resources.

Device Central contains profiles for popular mobile devices, allowing you to check support for Flash, bitmap, video and web content. The “web” tab in particular is useful for mobile developers because it gives information on HTML, WML and XHTML version support.

Some popular devices are absent, for example iPhone, but Adobe publish device profile updates occasionally (which you have to register to download).

I’ve actually used Device Central to preview logos and other images used on my XHTML MP pages. Previewing logos straight from Illustrator on smaller screens (especially clamshell Nokias) helped me make some tough decisions, so it’s worth giving Device Central a go if you own CS3 and haven’t tried it yet.

Mobile Web Design book review

Drawing on Cameron Moll’s experiences developing for mobile devices, Mobile Web Design aims to unite mobile web design with web standards. It features facts, statistics and practical advice, and even includes sections on testing and promoting your mobile site.

Split across 9 chapters (just over 100 pages), Mobile Web Design is a concise guide to all the major issues facing developers and designers today. Statistics are included covering the penetration and growth of mobile devices, presumably targeted at anyone trying to sell the idea of mobile web development to their boss or clients. It also contains discussions of cultural topics beyond practical advice. I was particularly intrigued by the section on the concept of mobile itself:

Mobile, the user; not mobile, the device. Mobile is more than just being wireless.

Moll is very clear about the limitations of the mobile web, covering carrier issues and standards, and explains the unique opportunities presented by this technology. Getting developers to think along the right lines is discussed particularly well in the “PC nearsightedness” section, and these arguments are related to current issues including the iPhone and even the term “cell phone” itself.

In the chapter “Four Methods, Revisited”, Moll expands on his series of articles entitled Mobile Web Design: The Series. The four approaches discussed are: do nothing, reduce images and styling, use handheld style sheets and create mobile-optimised content. Each approach is illustrated with real world examples along with the advantages and disadvantages.

Our web applications (at Helicoid) use the fourth approach, where we create separate sites for mobile devices. We’ve learned the hard way about the issues and best practices relating to this. We’d have saved a lot of time had we been able to read Mobile Web Design beforehand, and our experiences closely follow Moll’s advice.

Home 3G: Femtocells

Have you ever noticed how mobile services seem to follow an inverted Moore’s Law?

Moore’s Law states that the number of transistors in an integrated circuit doubles ever 18 months. Using this as a measurement you can predict the technological improvement in microchips.

Mobile services, however, got it right as soon as GSM landed. Making calls was easy, the clarity was good enough. Don’t feel like calling someone? Send an SMS instead!

Ever since then, mobile operators have been trying to recreate the incredible profitability of SMS and calls. The last few years have seen a lot of talk about micropayments, yet SMS was already there in the 90s. And more importantly, people wanted to pay for it.

Perhaps as a way to drive next generation services to a larger number of customers, Nokia, Siemens and Thomson recently announced plans to co-operate on “home 3G” through the consolidation of femtocell technology.

Access points integrating conventional wireless and residential 3G have already been announced. Yet as far as I’m aware, the fundamental practicalities have not been divulged: if I have a femtocell, will my phone automatically use it when I’m at home? Does that mean my calls will be routed through my broadband? Will this be a service provided by my mobile operator? Will it be cheap?

Meanwhile, mobile operators seem to see this as another way to deliver digital content instead of enhanced quality of service. “Home 3G” is cited as another way to sell music, TV and films. This could be a market of diminishing returns in the UK, irrespective of what statistics show about Japanese mobile music sales.

Such technology coupled with recent technological improvements in handsets makes me wonder about the future of the mobile web. The movement away from WML to XHTML MP was welcome, but slow. Meanwhile, devices like iPhone already have desktop-quality browsers.

Hopefully all we’ve learned creating mobile-friendly sites will continue to be built upon by taking the unique nature of mobile devices into account during the design process. Either that or customers will have to sit there zooming and scrolling with their touch screens, give up, and use their laptop instead.

UK flat-rate data hotting up

This will be of definite interest to people in the UK: Orange are going to be offering flat rate data plans. This could coincide nicely with the recent rapid growth of mobile social sites, since GPRS/3G (or even SMS) end up being restrictively expensive for regular use. Perhaps we’ll see a UK-based Twitter based on mobile web technology instead of SMS!

Meanwhile, I’ve been reading Johann Burkard’s mobile web posts. He’s been posting useful tips for mobile web developers over the last month.

If you’re writing about the mobile web, let us know so we can learn from you and share your links with our readers.

W3C Mobile Web Best Practices checker

The W3C Mobile Web Best Practices checker validates pages using tests defined in the W3C mobileOK Basic Tests. The tests produced results comparable to the .mobi tests, although they have no charts or other high-level visual indicators.

Of course, it’s best to take mobileOK results with a pinch of salt. The usefulness of some of the tests is debatable—mobileOK is still being fleshed out.

Their stance on scripting seems overly harsh, considering popular mobile browsers support javascript, and in Opera’s case they’re actively exploring more sophisticated javascript support (possibly inspiring mobile web 2.0 over the next few years—it already supports Ajax.) Their assertion that javascript will reduce battery life is also weak—where’s a reference with research into the reality of this?

While pointing out that sites shouldn’t rely on scripting is useful, promoting sensible use of scripting would also be beneficial.

Nothing beats real testing on phones, yet I expect many developers will try and get 100% passes for their sites through this tool and only test on one or two devices. Perhaps the validator should automatically flag a site as failed, and say, “now talk to your customers and see if your site actually works on their phones!”

Update: Sean from the BPWG pointed out this additional validator: http://validadores.tawdis.net/mobileok, and said the BPWG and .mobi will be collaborating on an open source validator.