You cannot build an app in “HTML5″, it is not a new language that iPhone or iPad applications are written in. It wouldn’t be far from asking someone to build you a website in “Web 2.0″.

An Example

What HTML5 is, is a ‘friendly name’ for a selection of new tags in HTML that a browser can understand (if compatible).

An example its simplest form, is the new HTML5 tag: “placeholder”.

Take an input field on a standard website form; and imagine the space where you would typically enter your username, email address, post code, or anything along those lines.

With HTML5, you can add a placeholder, some greyed out text saying “Enter your username” that sits in that box until you clicked into it, when you click into it, it disappears.

You’ve been able to do this for over 5 years, but only by using around 10 lines of javascript code, now that it has been pulled into HTML5 you can execute it simply with the following addition:

So HTML5 tags range from something as small as a placeholder, to the ability to detect a user’s GPS location, show a video on a web page without using flash or requiring a javascript player. Some of the more advanced steps and editions include the ability to save local files, caches and databases on the visitor’s computer – helping to make heavy websites operate faster.

Using HTML5 in iPhone and iPad Apps

Moving on to apps, offline storage using HTML5 is available to use whether you’re making use of HTML5 inside an application, or on the device’s browser. As an example, try to log into GMail using Safari from an iPhone. This is a great example of HTML5′s local database usage. Your email is saved locally, so that when you’re using the browser-based email client it’s not constantly having to send data back and forth.

The other thing to bear in mind is that there is no such thing as a HTML5 iPhone Application, you can use HTML in an application if you’re showing what’s called a “UIWebView“. Take one of our iPad magazine applications for example; when someone opens an article’s easy-read text window on their iPad, what they are really looking at is a HTML page that has been downloaded to their device. That same page would look exactly the same in a web browser.

You could have a mobile website, which someone could see through Safari on the phone, or you could have a application that shows a webview window, displaying a HTML page that’s either on the internet (and downloaded) or saved on their phone having been downloaded with the application from iTunes.

This is one of the best and most concise articles we’ve read on this recently and well worth a read:

http://adage.com/article/mediaworks/a-hotlink-costs-advertisers-magazine-ipad-editions/231581/

Our own view is that there should be further scope for creating ad real estate within each edition. The recent growth of tablet editions has opened up some interesting possibilities for marketers and publishers alike and there will doubtless be real improvements in how advertising is created and served to the new market of digital readers. As part of our own product development we already have a highly sophisticated ad serving model under construction, which could offer highly credible revenue streams for our clients. Watch this space in early 2012.

Naturally readers will expect a certain level of functionality within their tablet edition, but we suspect that many would take lower pricing of an issue and simple content delivery over higher pricing and greater levels of rich media. This is a balanced decision which should be taken by the publisher based on what they know about their readership, not taken by the developer who may not fully understand individual markets. Readers of a technology magazine may be willing to pay a premium for enhanced content over the print edition, but readers of a niche trade title may take an entirely different view.

Readers are seemingly willing to pay similar prices for tablet editions as they would for print editions, but each market is different and it’s important to get this right.

What we have seen is a shift towards simpler tablet editions at pricing similar to print editions. A complex app may not suit your needs and your readers may not have the appetite for this. You should also consider download sizes as many of the higher profile complex apps can take 45-60 minutes to download, which is frustrating for the reader and can lead to poor reviews.

The market is now evolving and maturing and we can see that there isn’t one answer for all publishers, but there is always a solution available here.

As part of our ongoing product development our magazine framework will, of course, be Newsstand compatible and we’re upgrading client publications and releasing updates now. The gradual opening of a truly global market for publishers will undoubtedly bring with it new challenges for media owners, not least of all the new wave of competition form overseas titles looking to penetrate all regional markets.

We’re working hard to make sure the entry to market can be fast and cost effective and have released an entry level version of our magazine framework which is priced at £1400 for build and £249 per issue release. No download fees, no per page fees…. in fact, no hidden fees whatsoever. Publishers can now enter and test the market with a relatively low budget and no need for re-purposing of content and upgrades of features within the app are simple.

We recognise that all magazines are not the same and one size does not fit all. This is why we offer a range of potential options, all of which are flexible.

11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected

This is quite simple, but pay close attention to the “in an app” words. Apple are saying that if someone wants to buy content, functionality or services in an app, you must use their system that requires users to enter their password to pay via iTunes, Apple will take their 30% commission. However, they then go on to say:

11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

Meaning, that if you create an app where users can buy clothes, shoes, cars, pets, a haircut, anything that is a physical good or service… you must not use the In App Purchase API.

Between these two rules, we can assume then that you are allowed to take a user’s card information, PayPal details, or similar details to process transactions using your own systems and software. How you process and handle those transactions is your responsibility, the onus is on you to ensure any orders are fulfilled, data is kept safe and in accordance with any laws. Your new customer would have completed a transaction directly with you.

11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Developer Program License Agreement.

Onto the subject of subscriptions. First of all, remember that when Apple refers to a subscription, they aren’t only referring to magazine subscriptions, but anything at all. A subscription to a music service, a dating application, an on demand video channel and hundreds of other possibilities.

In clause 11.12, Apple explain that if you are trying to offer subscriptions, you must do this using the In App Purchase API.

11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected

Inside your app, you can not tell your readers to visit your website to purchase the same product that is available for sale in the app using In App Purchase. For example;

I download your magazine, I choose to subscribe but before you ask me for my iTunes password to confirm the payment, you let me know that I could also buy the same thing from your website, and give me the opportunity to buy it from there.

But before you panic, look at this next clause:

11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app, as long as there is no button or external link in the app to purchase the approved content. Apple will not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app

So what Apple are now saying is that you are welcome to sell subscription to your app on your site and Apple will not expect any commission. So let’s use another example:

I visit your magazine’s website, I see an offer to purchase an “iPad only subscription”, I click through, I make my payment (using my credit card, or PayPal account), at which point I have purchased a subscription. I then open the iPad application, and somehow, verify that I should have access to issues in the app.

Taking the payment on your website, and verifying whether a user of the app should or should not have access to issues of the magazine is something for you and your developer to sort out. But Apple seems to be quite clearly saying they do not have a problem with this functionality existing.

Out of interest, we have had features similar to this in place on our magazine framework since September 2010, which was approved by Apple.

Grey Area 1: ‘Super subscriptions’

Some of our clients offer free access to issues in the app if the reader has already purchased a print subscription. This continues to be possible based on Apple’s guidelines. However:

1. What happens if a publisher selling a 12-month subscription inside their app, using the In App Purchase API, wants to offer a free print editions, essentially bundling the iOS and printed versions together.

1.a. The publisher would need to obtain the user’s postage information. The information that Apple forwards to publishers (if the user allows it) is limited to Name, Email and Zip Code. This wouldn’t be sufficient to post a printed copy. The publisher would need to provision the ability to collect full postage information within the application. Apple would allow this.

1.b. Would Apple consider this a “physical product”, thereby making it impossible under clause 11.3?

Grey Area 2: Single Copies

Imagine a reader has purchased a copy of your magazine at the airport newsagent. You, as the publisher would like to offer anyone who has a physical copy access to that same issue on the iPhone or iPad.

Would that constitute having sold someone content available in an app without having used the In App Purchase API, therefore breaching clause 11.2? Or would this be considered simply ‘unlocking’ functionality – which is permitted?

In conclusion

We’ll continue to decipher Apple’s policies on subscriptions and in-app purchases as best we can. These concessions do seem to imply that Apple are happy for magazine publishers to create their own system for charging readers for content. These amendments to Apple’s policy aren’t going to make everyone happy, but they do create opportunities for publishers and their developers to work together to find solutions that best suit them, as has always been the case.

Apple’s in-app purchase API may remain the most convenient and user-friendly way to make purchases from within an application, but there’s still scope to create an intuitive enough alternative that avoids the 30% iTunes vendor fee. The doors haven’t been closed, it’s simply a question of developers thinking laterally to create a user friendly solution.

We have been working with publishers since before the iPhone and the App Store even existed. As this marketplace and group of devices has grown (dramatically) at Stonewash DD&AG, we still haven’t seen anything that seemed unfair or detrimental to a publisher’s success on Apple platforms.

In this post, I will attempt to explain why the 30% share that Apple take is more than fair.

Cost Comparison: Physical Newsshelf versus Apple Newsshelf

Ignoring the cost of content creation (as this remains the same, regardless of platform) a magazine might cost anywhere between 25p and 125p to print. I realize this is a sweeping generalization, but I’m going to take 50p as a reasonable print cost.

Add into that the logistics cost of shipping magazine from your printers / warehouse, via your distribution company, to the retailers. Per magazine, this cost is usually extremely low, for the example, I’m going to allocate 2p per copy for logistics.

Using an example on-sale price of £2.99, we know that between the retailers and distributors, the commission is around 52%.

For each copy sold, £1.47 is paid out by the distributor. Subtract then the 50p for print and 2p for distribution and you’re left with 95p per print copy sold.

Before you disagree with our estimation of print or logistics costs, bear in mind that we have not taken in to account the cost of wastage (the fact that for every 100 magazines on a shelf, you’re likely to sell between 50 and 75 of them), and listing fees (the fees that large retail chains charge publishers for shelf-space).

In comparison, an app (or in app purchase) that sells on the iTunes store for £2.99 will pay out £2.10 to the developer or publisher for every iPad issue sold.

Why don’t Apple give us information on our readers?

When you purchase an App on the iTunes store, there is a certain level of trust between the end-user and Apple that their information is safe. In our opinion, this is what has helped the App Store grow into what it has become today.

We often hear people talking about how unfair it is that they cannot get the names and addresses of people who are buying their magazines.

There are two things that should be taken into consideration here. First and foremost, you don’t know who is buying your magazine from a newsagent’s shelf. This has never caused an issue before.

Apple stores private information on their customers, by ensuring this information remains private, people have the confidence to buy applications from developers and software houses they have never heard of before, because they know their contact information remains private. Did you know, that when you buy something on the Android Marketplace the developer can see your full name and address. The majority of developers are not big corporate companies with security and data-protection plans in place, but individuals, based all over the world.

The thing that most people have failed to understand when debating this topic is that Apple have never had a problem with publishers asking their readers to fill in information inside the application. We have been advising our clients of this for years now. Apple have never prevented publishers from collecting information and data from their readers, this is simply something that a publishing company would have to factor in to the build of their application.

In most cases, poor advice or publishers working with developers who do not understand their market or needs has lead to the publishers need for user information not being fulfilled.

What does the 30% cover?

The Marketplace
The other misconception is that Apple earn 30% on every purchase without having to do anything… this isn’t true – by a long shot.

First of all, Apple as a company is responsible for creating a bona fide market for mobile software. Buying software for your smartphone has existed for years, I remember buying games and applications for my Palm Treo in 2004.

What Apple have created in the App Store is a well liked and trusted platform that everybody understands. Through the success of the iPod and iTunes, they have ended up with hundreds of millions of user accounts with credit cards plugged in and ready used to the concept of purchasing digital-only goods in a single click.

The publishing industry has been learning that hard way that people, in general, are not interested in paying for news and magazine content on the internet. Yet, because of the way in which Apps have been marketed (by Apple) as dynamic, fun and valuable, there is now a rapidly growing market of people willing to spend their money on digital-only goods.

Before Apple released the iPhone and the App Store, no body really understood the benefit of small applications for your phone, and no body wanted to spend money on them.

The Approval Process
We have pushed hundreds of apps through Apple’s approval process, and I’ll admit, it’s frustrating. The process takes between 5 and 15 days, in which time Apple staff will download, install and test your software to make sure it’s free of major bugs, and is not malicious software.

As a result of this, buyers feel confident that the applications they are downloading to their device are safe, virus free and functional.

However, in contrast, last month MSNBC published a study (1) showing that Android-based malware is up 400%. The open nature of the Android Marketplace means that developers are free to create malicious software and upload them to the marketplace (viruses, applications that attack Wi-Fi networks and perform other tasks).

The outcome of Apple’s human approval process is a trustworthy store where people are confident to purchase and download applications without risking their device’s wellbeing, their privacy and their personal information held on the phone.

(1) Referenced MSNBC story: http://technolog.msnbc.msn.com/_news/2011/05/11/6624172-study-android-malware-up-400-percent

http://www.thedrum.co.uk/rar-london-agencies/2011/40/stonewash-ddag/

We’re not about to sit back on our laurels and have plenty more good work in the pipeline to ensure we climb higher in the annual rankings for 2012.

If you would like more details of our Android frameworks or our development of frameworks for the soon to be launched Blackberry Playbook then do contact us on team@stonewashddag.com

The challenge for us was to create a system whereby content could be sold online quickly and easily to readers without blocking our large areas of the site. We worked closely with the publishers to build a micro payment system using PayPal which allows readers to purchase individual features at low cost. Simple, but highly effective.

For information on how Stonewash can help with your website please contact us on team@stonewashddag.com

Next year you can expect to see us launch more frameworks for Android, Blackberry and Apple devices and work is already underway on a suite of new products for the media industry.

We’d like to take this opportunity to wish all of our clients and supporters the warmest seasons greetings and we’re looking forward to an eventful 2011.

We were recently approached by Roast Restaurant to create and app and an external touchscreen menu system for their restaurant in Borough Market, London. We couldn’t wait to get our teeth into this one and the result is a highly interactive app with games, menus, booking contacts and news updates. The touchscreen menu system was a real challenge and involved mounting a large screen behind 30mm thick glazing that worked by magnetic sensors allowing the user to touch the screen and access the functions from outside. We sourced and used the very latest in touchscreen technology as well as building an easy to follow back end admin area for the staff.

As with all of our projects we worked closely with the client to ensure the finished product not only exceeded their expectations, but was also delivered on time.

For more information on our custom build services please contact rob@stonewashddag.com

The app can be branded and downloaded from iTunes by your readers and draws content directly from your website news feeds as they are updated. The result is an app that’s easy to use, requires no maintenance or uploading of content and delivers up to the minute news to your readers on the go. The app also has provision for live linking advertising banners which can be updated as often as you choose.

We’re understandably very pleased with the product and are already seeing a great deal of interest from the B2B publishing market.

For more information please contact rob@stonewashddag.com

Our new offices can be found at 55 Farringdon Rd, London, EC1M 3JB and our doors are open for business as always.

We are already seeing a huge growth in geo-location dating apps and great potential for subscription and advertising revenue streams here. By creating a fun and easy to use app framework we’re able to offer our publishing clients a product that is capable of generating real revenues, without the need for administration or straining existing resources. Our in app subscription system allows users to quickly purchase 30 day, 90 day or 365 day subscriptions so as to use the full in-built messenger features.

The app can be downloaded for free and includes:

• Easy profile set up and image upload
• Option to receive push notifications when others have viewed your profile, winked or sent a message
• Option to hide profile or block other users at any time
• Search by recent activity or by who’s nearest to you
• Users can easily opt out of GPS location tracking
• The in-built messenger system (premium subscribers only) shows when your message has been read by the recipient and keeps your messages until you choose to delete them

The app is taking online dating into the future and is proving highly addictive! With a pre populated database of active users there’s no need to worry about releasing a dating app with no profiles to search.

The app is ready to go as a white label framework, branded to your requirements and all enquiries should be directed to rob@stonewashddag.com

The iPad promises to open up a global market where print distribution is uneconomical and we can already see that there are huge opportunities for publishers in what is likely to be another rapid growth market. With leading publishers already lining up iPad versions of their titles we’re ready to offer our clients the opportunity to enter this new market from day one.

The new framework includes a host of features allowing readers to swipe through pages as well as viewing text only and image galleries. As with our iPhone app framework we’re fully committed to ongoing development and fine tuning to make sure our product stays at the forefront of the market and fully meets the needs of our publishing clients.

For more information or a demonstration please contact us at team@stonewashddag.com

Commenting on the release our Business Director Rob Grainger:

“We set out to try and move away from static jpeg images of pages, which aren’t user friendly, and our objective from the start was to create a more engaging format that would not require exhaustive re-purposing of content by the publishers.We’re worked closely with media owners to develop an app that delivers content in a way that best suits the device. The result is a more user friendly and engaging experience for the reader.”

For more information on our Stonewash Magazine Framework email us at team@stonewashddag.com