My client wants to do an iPhone app because she's found that people are significantly more likely to use the iPhone app over a mobile optimized site. The iPhone app is very simple - it just displays a couple images and some text. As a programmer I'd much rather do a mobile site given the simple nature of the content. From a technical perspective I feel that it's overkill to use an iPhone app in this situation.

Does it make sense to build an iPhone app when a mobile site would suffice, simply because your users would much rather it be an iPhone app? Is there anyway to easily convince users that a mobile site is just as easy to use?

  • 1
    If the app is that simple, you should do both: you will have fun, and your client will be happy. Commented Oct 22, 2012 at 2:59
  • 2
    You seem to be putting your own needs above those of your users.
    – Caleb
    Commented Oct 22, 2012 at 3:11
  • 9
    "Does it make sense to build an iPhone when a mobile site would suffice, simply because your users would much rather it be an iPhone app?" - simply because? You have your logic backwards. Commented Oct 22, 2012 at 3:17
  • 3
    This seems like a poll question. Furthermore the correct answer is pretty clear, do what your client wants, who cares if its "overkill" if your client has a valid reason it shouldn't matter.
    – Ramhound
    Commented Oct 22, 2012 at 12:50

7 Answers 7


The simple answer is to develop a website but build it as a mobile web app. If you are more comfortable with building a web site, or feel it will be faster, then this is the way to go.

Users can still 'install' it (create an icon on their home screen, where you specify the png to use for the icon), you hide the Safari toolbar, and it functions just like an app.

Here's the Apple page on creating web apps

The benefits of this are

  • cross platform - the web app will work on Android, WP, even Blackberry!
  • you can update content - e.g. text, images without updating the app
  • cheaper and quicker to develop

I don't know if you can put these type of web apps into the iTunes store or not.

  • 2
    So basically you are just creating an HTML5 web application, and then telling/showing the user how to associate an icon with it? Commented Oct 22, 2012 at 2:57
  • Or just an HTML (any version) page. The key is instructing iOS to run full-screen Safari, and specify icons in the HEAD section. AFAIK a user can't choose their own icon to use. Commented Oct 22, 2012 at 3:31
  • 7
    -1 Web apps are far from "cross platform" from usability standpoint. You can create iPhone-like web app, but such app will be like sore thumb on Android and Windows Phone.
    – Euphoric
    Commented Oct 22, 2012 at 5:45
  • 4
    @Euphoric you might want to apply a different style sheet according to the platform, but you don't need to. Compare with trying to install an iOS app onto your Windows Phone and you'll find that web apps are one of the most cross-platform techniques available. Commented Oct 22, 2012 at 6:27

If the webpage is really that simple, you shouldn't make it into an app. I can give you one reason, but it's a very good one:

Simple applications usually don't pass through appstore reviewers.

From https://developer.apple.com/appstore/resources/approval/guidelines.html

2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected

If you try to upload such an app, you will probably get a rejection stating "the app does not use native iOS functions" or something similar.

If you want to create a simple iOS app, you have to think what functionality will be added against a web page.

  • 1
    +1 You aren't building an application, you are building a website(from the sound of it). So it should be a website, not an application. It shouldn't even be referred to as web app, don't say HTML5. It's just a mobile website (images and text).
    – Will
    Commented Oct 22, 2012 at 16:12

Just last week I published apps to both Google Play and App Store that were a little more than dedicated browsers (WebView) for a responsive web site and some sugar on top of it.

This gives you:

  • HTML5-based fast development of majority of the app as web page
  • Presence in the respective App Store of the device
  • Users can install the app in regular ways (no complicated instructions to get the icon to home screen)

But you still retain the benefits of native app:

  • You can always move more code to the native side later
  • Make use of APIs that are off limits to browser based webpages, e.g
    • advertise the app as routing app in the new iOS Maps
    • let the Passbook open the ticket in your app, etc

I'm sure that Android too has multitude of APIs that are forbidden to webapps.

BTW. From my own experience - stay clear of cross-platform frameworks. Even for such a simple task I got my ass bitten by one of those and I ended up rewriting the whole thing in native language.


I feel your pain, many apps should be part of the web, and developed with web technologies.
But that's a technological stance, your client probably doesn't care.

My guess is this kind of client aren't really going for the app as much as they're going for the appstore.

You might be underestimating the visibility the appstores may confer to a client's publication, here.

"Free Advertising!!!1!" might be all your client sees.

Still, they, the client, might be underestimating the actual costs implied. But in their mindscape those new costs will be balanced by the "new" monetization mechanisms appstores allow.

Then they are almost certainly overestimating the actual monetization an appstore can raise for their (editorial, I suppose) product in the current moment. They're not sporting Angry Birds, after all.

Also they're probably delaying their time to market quite a lot, by going for an app solution.

Unfortunately this kind business plan:

  • Build App
  • ???

Seems to be all the rage nowadays.

  • 2
    tl;dr: You need to be in the app store. Commented Oct 22, 2012 at 3:58

You're not giving your client enough information to make an informed decision.

  1. Are they aware of the iPhone app approval process?
  2. Are there features where users need access when they aren't connected?
  3. Do you have to worry about sensitive information stored on the phone?
  4. What about devices not made by Apple?

Beware of "it's easier for me to build a website" because there is compentition out there who will be more than happy to build an iphone app.


Admittedly, I have a personal bias toward native apps, but I think there's really no black-and-white answer to this. Here are a couple thoughts on web apps vs. native apps:

  • Web apps are nice if you want to avoid the hassle of becoming a member of the Apple Developer Program. Without this, you cannot install apps on devices or publish them to the App Store.
  • Then, of course, there's the effort of learning XCode and Objective-C (if you don't already know them).
  • On the other hand, native apps tend to be more responsive (my own subjective experience).
  • If the app must be able to run "offline" (when no Internet connection is available), then a native app is really your only realistic option.

In your case, I'd weigh your client's requirements against the pros-and-cons of web and native apps.

I'd also add that writing and deploying a native iPhone App doesn't NECESSARILY require a presence in the App Store. So-called "In-House Apps" can be written and deployed in an enterprise setting. Consider this: http://help.apple.com/iosdeployment-apps/mac/1.1/#app43ad6a6a

  • If the app is for customers, "In-House" won't help...
    – Sulthan
    Commented Oct 23, 2012 at 8:54
  • Indeed, but since the question never clarified this point, I felt it was at least worth mentioning.
    – Avian00
    Commented Oct 23, 2012 at 9:33

Given your problem description I'd go for a mobile site masked as an app. In general, many mobile apps are just HTML5 sites that may or may not run locally. This can be a great start to quickly develop a multi platform app which will work reasonably OK on many types of mobile devices without having to rework much of the code. Having said this, there is one caveat: HTML5 isn't the king of speed when doing heavy duty stuff. When it is time to do some processing intensive code which isn't available as some piece of middleware for the platform(s) you're developing for, the code can run rather slow if you depend solely on JavaScript to do the processing and you should consider taking it to the next level (Native app).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.