Journal

Designing iPad Apps

PC Pro logo Posted: 7th October 2010 | Filed under: Press Articles
Author: Paul Ockenden
First Appeared in PC Pro 2010

I thought I’d write a bit about designing applications for Apple’s iPad.

There are really three ways to attack this, the first being to write native Apps. To do this you’ll need to sign up to Apple’s iOS developer program. This costs £60 a year, and as well as the developer tools you also get access to things like beta releases of new versions of iOS, long before they get a public airing. A possible downside is that you need a Mac – Apple’s developer tools are, hardly surprisingly, Mac only. You’re just as likely to find Apple releasing a Windows version of Xcode as you are Microsoft porting Visual Studio to the Mac. You could of course use some kind of Hackintosh (a way of getting non-Apple PCs to run OSX), or even try running OSX inside a VM. Both are possible, but both are strictly against the OSX licensing conditions, and frankly, for most people they’ll be a lot of hassle. You can pick up an Intel based Mac Mini on eBay for a couple of hundred quid which will be more than adequate for creating iPad or iPhone apps.

The iOS Developer program costs £59 a year, and gives you access to pre-release versions of iOS as well as developer tools and advice

A bigger problem might be that you’ll need to learn Objective-C. Many people who’ve learned C++ in the past think that Objective-C will be similar, but it isn’t. It’s more like old fashioned Kernighan and Ritchie C, but with Smalltalk mixed in for good measure – in fact, some describe it as the worst bits of C, with the clumsiest bits of Smalltalk layered on top, although I think that’s a bit OTT. You can use C++ methods, but the Apple frameworks are in Objective-C so it really is an extra skillset that you’ll need to learn before you can start working with the iPad GUI, or other parts of the system. As someone who’s done a lot of C++ in the past I find things like the lack of constructors/destructors a real pain – initialisation and freeing both have to be done manually. There’s only one name space too – you can forget your public and private objects, it’s like going back to old-school programming.

As well as the new language, you’ll also need to learn Cocoa, the framework at the heart of iOS apps. And it’s philosophically very different from Windows programming, but that’s only natural, given how very different the iPad and Windows user experiences are.

If buying new hardware and learning whole new programming languages and frameworks pushes you too far over the pain threshold, the second option is to use some kind of app platform that allows you to target the iPad. The most well-known are probably Unity 3D and Stonetrip ShiVa3D which are both primarily for creating games, although they can be used for other kinds of apps too. Both of these allow you to create apps on a Windows PC, and then target them onto an iPad.

Although I’m perhaps being a bit over cautious here, I’d be worried about going down this route, certainly for any high profile project, or one with significant manpower and/or financial investment. The problem is the on-off nature of Apple’s app approval process. First they were happy to allow apps built using 3rd party tools. Then they banned them, resulting in a big PR spat between Adobe and Apple, and then Apple decided to allow Flash and other similar apps again. Mainly, it seems, to appease EU regulators. But who’s to say that this notoriously fickle company won’t change its mind again in a few months time? I know that nothing in life is certain, but Apple’s SDK and app deployment rules mean that I certainly wouldn’t bet the farm on a Unity based project. But perhaps you are braver than me?

There’s another third option, though, and it’s perhaps a slightly easier although less obvious one: create web based apps. The iPad has a brilliant web browser, which has decent CSS and JavaScript support. You obviously won’t be using it to create the next Need For Speed or Angry Birds, but for a typical business type application it’s perfectly adequate. You can make your browser based app run like any other iPad app, taking over the full screen (without the address bar etc.), and using webkit CSS to give your app the iPad/iPhone look and feel. You can respond to gestures such as touch, scrolling and scaling, and even put an icon on the Springboard. Best of all, you can even cache your browser App so it’ll run even if the device doesn’t currently have Internet access.

I was going to spend some time explaining how to do all of this, but a quick Google revealed that someone else has already done it, and probably explains it better than I could, so take a look at here if you want to know more about creating JavaScript based browser apps .

There are a few iPad quirks that you’ll need to know about, though, and these are true whether you’re writing HTML based apps, or just wanting people with iPads to access your existing websites and web applications. The first and most obvious observation is that you can’t use Flash. Perhaps Apple and Adobe will kiss and make up at some point, but until that happens Flash is a big no no. But I’m sure you already knew that. Another gotcha is scrolling blocks within things like divs and iframes – the normal one finger swipe gesture triggers window.scroll() in Safari, meaning the whole page will scroll rather than just your block of text. There is a two finger scroll gesture available on iOS devices which does what you need, but in my experience most iPad users don’t know about it. So I’d really advise you not to have scrolling text blocks – at least, not for important content.

Another one that’ll bite you on the bum is that fact that you can’t do a proper mouse hover on an iOS device. In fact, most touch-screen interfaces won’t give you hover support – it’s obvious why, when you think about it – the device only really knows your cursor/finger is at a certain location when you touch the screen, and by that point you’ve already generated a click. There are various hacks available to get round this, and mobile Safari does include an onMouseover event of sorts (which involves a quick tap, so isn't really a hover), but I’d avoid it because the usability sucks as it’s really tricky to use.

Because the whole mouseover concept isn’t suited to a touch interface my advice would be to engineer (or re-engineer!) your user interface so that hovering it isn’t required. Touch screens are all about actually tapping the glass, not hovering over it.

Something else to watch out for is fixed positioning (i.e. where you specify the exact x/y viewport coordinates of a page element, rather than letting the browser build the page). Note that I’m not taking about absolute positioning, where you specify the place on the page where you want an element to appear – with fixed positioning you’re specifying its location within the browser window. If you scroll the page the element stays fixed. People often use this for navigation, or headers and footers.

The problem with fixed positioning on an iPad is that because of the zoom/pan functionality, the browser window isn’t the traditional viewport, which on IOS devices is a fixed window, the size of the device minus screen furniture – it isn’t movable, scrollable, or resizeable. What you’re looking through on an iPad is yet another layer sitting on top of the viewport. And so as you zoom and scroll around the screen, elements that are fixed to the viewport can end up all over the place, even off-screen. It’s really not what you want at all!

It’s not all gloom and doom though – there are a few great things about developing web based apps for the iPad. For starters, you have the web designers dream of having a fixed size window. Well, actually there’s two – portrait and landscape. But you can easily switch between them using CSS:


<link rel="stylesheet" media="all and (orientation:landscape)" href="land.css"/>
<link rel="stylesheet" media="all and (orientation:portrait)" href="port.css"/>

You can also make life easier for your users by presenting the appropriate keyboard for any text input fields. For example, if you use HTML5 style <input type="email" /> your user will see a keyboard with the @ symbol and the domain endings (.com etc.) visible. But use ‘tel’ instead of ‘url’ and they’ll see a keyboard suitable for entering telephone numbers. These are all standard html5 input types, so your pages will still validate properly.

Because of a limited screen size (OK, it’s bigger than an iPhone, but it’s still a really small screen), and the lack of input facilities means that, where possible, it’s best to simplify processes as much as possible. Of course this is true for any Web application, but targeting the iPad forces you to really concentrate on reducing the swipes and touches. A great rule of thumb is “Minimise Input, Maximise Output”.

Given the App/Generator/Webapp choice, even if you don’t decide to go for the full Objective-C development environment it’s probably still worth you joining the iOS developer programme. It’s £60 a year, which even in this time of austerity shouldn’t really break the bank, and might even pave your way to a small fortune – a successful App hosted within Apple’s App Store can easily rake in tens if not hundreds of thousands of pounds.

Now go and build some fantastic tablet apps!