By type of app, I’m not talking about whether you’re producing a game, news, productivity or any other kind of app, but how the content inside of it will be updated (if at all).There are a couple of options:
- All of the content (text, images etc) for your app will be contained inside the app itself and won’t be changed (not regularly, anyway), or;
- In certain parts of the app you pull in some of the content from elsewhere, such as your website (eg. a news app pulling in the latest headlines and news articles).
In some cases this will be a fairly obvious, in other cases you will have to make a call (and may need to consult your colleagues if they are providing the content). There are broadly two or three types of app, depending on your definition:
Self-contained (‘static app’)
The app can be downloaded from the App Store (after being submitted to and approved by Apple) in the regular way. All of the content in the app that the user sees is contained inside the app and no content is brought in from outside (eg. a website or XML* feed).You may still be able to ‘push’ stuff from the app (eg through Facebook / Twitter) but all the content on the app will remain the same. The up-side? Your app (should) be extremely stable and it doesn’t matter if your user has a web connection or not.The down-side? You want to update the content in it quickly? Tough! You’ll have to submit an update to Apple, and likely wait a few days.
*XML (Extensible Markup Language) is a way of organising data, useful in this instance for pulling content into your app.
Example: Angry Birds, Collins English-Italian Phrasebook & Dictionary with Audio.
Situations / types of apps this could be good for: games, language learning apps (languages generally don’t change that quickly) or any app that it might be essential for you to use abroad (and therefore likely to want to avoid excessive roaming data charges).
Hybrid app (‘dynamic app’)
Still a bona-fide app that you can download from the App Store but some parts of the app are said to be ‘dynamic’.The advantages of these dynamics areas is that they can always have up-to-date information and even be controlled remotely (for example, you might include a competition button inside your app that can be turned on or off just by changing some XML code outside of the app – viva flexibility!).The downside is that if the user – at the moment of accessing the app – has no Internet connection then they might end up with out-of-date (or no!) content in these areas.
One extra point to consider is that if some of your content is dynamic (and therefore coming from ‘outside’ the app) it means that you’re fine-tuned, perfectly-tested iPhone App could ‘break’ or not work as intended at any time (before launch, after launch, or even worse, while Apple is looking at it). How? If someone is working on the web content or XML that sends content to the dynamic parts of the app and breaks something, that could then have a knock-on effect on the app itself.This isn’t something that you should be afraid of or should put you off, but is definitely something to consider as part of your project. (A definite ‘lockdown’ shold be put in place to ensure no work is carried out on any dynamic areas of the app once Apple start reviewing it!)
Example: Time Out London – a mix of ‘static’ content and web/XML content from the timeout.com/london website. The Guardian – as a news app it needs a constant flow of new content.
Situations / types of app this could be good for: news apps, social media apps
‘Web app’
Apple also defines a ‘web only app’ in it’s Human Interface Guidelines. In my mind this isn’t really an app or at least what most people consider an app (you can’t download it from the App Store for one thing). However it is something you may want to explore as well.
I’m not trying to talk you out of doing a ‘static’ or ‘hybrid’ app but there are cases where a simple mobile website can be a better strategy and not just for ‘smaller’ companies either.
You only have to take a look at Google which – despite having some ‘bona- fide’ apps (Google Mobile App, Google Earth) – has largely opted in favour of optimising their websites for different mobile devices, including iPhone and iPad.Take a look at Google Mail, Google Calendar or Google Docs in the Safari web browser on an iPhone for example, and you can see they’ve achieved a great deal without any need to produce a ‘standard’ app.
If your own development team isn’t up to the task (or too busy to look at developing dedicated websites for mobile platforms) you can still use the methods I describe in Part Two of this guide to find a supplier to do this for you. Alternatively you can look into using one of the products or companies (eg Bmenu – bmenu.com) which specialise in these kind of solutions.
For instance, there are products out there which will automatically analyse the type of phone or device viewing your website.They will then use this information to automatically adjust the layout and content of the web page to match the size of the screen and to take advantage of any other functionality that may be available (eg. gestures on an iPhone). If you currently use a content management system (CMS) to update and manage the content on your website then it may also be worth talking to your CMS vendor to see if they already have a plugin or extra product that might take care of this for you.
Finally there is nothing to stop you mobile-optimising your website while completing an app project at the same time.There are benefits to both that don’t necessarily overlap.
Example: Google Mail, Google Docs, Google Calendar in Safari on an iPhone.
Situations / types of app this could be good for: Any developer who doesn’t want to be tied into the App Store platform and/or fancies developing for multiple platforms at once through the mobile phone web browser.
