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.

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.

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
• ???
• PROFIT

Seems to be all the rage nowadays.

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

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).