We are excited to announce that developers can publish their web apps to the Amazon Appstore without a manifest. As we continue to streamline the web app submission process our goal is to make submitting hosted web apps just as easy as submitting Android ones. Now all you need to do is supply your hosted web app’s url, instead of uploading an APK, and the rest of the process is exactly how you would expect. Fill in the app’s description, upload screenshots and define your app’s permissions which allow you to quickly publish web content to the Amazon Appstore. Let’s take a look at how this works.

Our web app submission process revolves around being able to take any online website and by submitting its URL it will be published like a native app to the Amazon Appstore. For customers who have websites that support responsive design, work well on mobile, and are looking for a way to distribute their site next to native apps, this is the best solution out there for getting hosted content in the Amazon Appstore. Additionally, they can monetize their website by setting a base list price or by using Amazon’s In-App Purchasing APIs. If this is your first time submitting a web app, you simply provide a url where you would normally upload a native APK.

Let’s take a look at how you can get your own web app ready for submission in four easy steps.

Step 1: Verifying Your Web App’s URL

You can now validate your web app’s URL right from the developer portal.

Simply put your URL in, click the verify button and the tool will let you know if the contents at the URL pass the preliminary submission requirements. We check for the following things:

1.      Is the URL properly formated

2.      Make sure that a URL does not return a 4XX or 5XX http status

3.      URL has valid security certificate

4.      Redirects don’t lead to an eventual 4XX or 5XX code 

Just keep in mind that users will need to have an Internet connection to access your site once it’s submitted.

Step 2: Declaring Web App’s Permissions

Once your URL has has been verified, you can select your app’s permission. Simply check off the options that apply to your app.

Step 3: Select Compatible Platforms

Then you can define on which devices this web app can be published.

While the Kindle Fire HD and HDX devices offer the best performance for web apps, make sure you test your web app on older devices to ensure the performance is ideal for your users. Intensive web games and anything using WebGL should be distributed on Kindle Fire HD and above.

One other thing to keep in mind is that while you can install web apps in the Amazon Appstore on any Android device that has the store installed, it will default to the native WebView on that device. This means you will not have access to the optimized Amazon WebView and will see a drop in performance. Make sure to test out your URL in the web app Tester and select Android Web View to see what it will run like on native Android devices.

Step 4: Agreeing to Distribution Rights

Finally, the last thing you need to do is check off Distribution Rights.

This ensures that you own the domain and the rights to publish the app. We will do our own verification to make sure you are in fact the owner of this domain and are not trying to publish another site to the store.

Wrapping Up

As you can see, the process of submitting a web app to the Amazon Appstore couldn’t be easier. Now that the entire process is done through the developer portal it should take you only a few minutes to expand your web app’s user base by making it available to millions of Amazon Appstore customers in nearly 200 countries. Better yet, you now have the ability to charge for your web app or add in-app purchases to create new opportunities to monetize your online content on mobile devices.

Additional Resources

Amazon Developer Portal -

• More about publishing HTML5 apps to the Amazon Appstore -
• Download the web app Tester - http://www.amazon.com/gp/product/B00DZ3I1W8
• Adding IAP to Your Web App - https://developer.amazon.com/post/Tx3LQBBJRUYE58P/Implementing-the-Amazon-In-App-Purchasing-API-in-your-HTML5-Web-Apps.html

- Jesse Freeman (@jessefreeman)

The Current HTML5 Landscape

In a world quickly moving toward mobile device adoption, there is a growing pressure for web developers to learn new languages in order to adapt to the ever-changing landscape of content delivery. For the past 16+ years, web has been the king of mass distribution. But now as app stores on mobile devices are driving huge monetization opportunities, how do web developers stay competitive in this new “post PC world”? The key is to understand how you can maximize your web app’s potential in the distribution vs. monetization model.

The Distribution Vs. Monetization Model

As developers look to create new content, be it a web app or native app, they should be thinking about the following model:

The distribution vs monetization model.

The concept is that the larger your distribution base, the better your chances of monetization are. Along the far side of the x-axis is the native mobile and tablet space, which is fragmented around several different platforms, and the individual platform distribution potential is much smaller. On the flip side, since all mobile devices and computers have web browsers, an online web app’s potential reach is staggering.

The reality of this however has been that even with the smaller distribution of mobile, developers are seeing much higher opportunities to monetize on those devices. On the web, we have seen more difficulty to monetize that content without the help of built-in systems like IAP (in app purchase) or integrated checkout, which are generally available on native devices through their app stores. The ideal solution would be to actually target both demographics, and the only platform we have seen that is capable of effectively doing that is HTML5.

Scaling Your Web App

When most developers hear “scaling a web app” they instinctually think about the backend or server side of things. But over the past year as responsive design has come into its own, we are finally seeing websites that can not only run on desktop browsers but elegantly reconfigure themselves to accommodate all the different viewports users are visiting with.

The most common responsive design resolution breakpoints.

The forethought that goes into building a truly responsive design that flows correctly from desktop to mobile phones is no small task but the opportunity for capturing the largest possible distribution is worth it. Gone are the days of splitting off your web traffic between a mobile only site and a desktop site because the cost of maintaining both grow exponentially. But what about still reaching native app stores?

But What About Still Reaching Native App Stores?

Some of the current solutions on the market for publishing HTML5 content next to native apps have revolved around the PhoneGap/Cordova model. These allow the developer to package the web app and submit it to a native app store. But there is one glaring downside to this kind of distribution; you lose the ability to maintain a single codebase. In an ideal world, you would want to simply redistribute your online app in a mobile store and keep the two in sync. This is some of the thinking behind our HTML5 web app resources for Amazon Appstore.

Own Your Content and Keep it Online

The last thing a developer would want to do is fork a project and end up maintaining multiple code bases to support each platform it is distributed on. So why not just keep your content online where it will get the largest potential for distribution and still submit it to an app store that offers you an entirely new way to monetize it? This is a fairly new publishing model that has been growing more and more popular over the past few years. It offers the best of both worlds since you maintain a single place were your web content can live and you gain the added benefit of being able to distribute your app in a native store. With that distribution comes the potential of increased monetization by simply charging for the app, using IAP or continuing with your current ad based model.

The best part is that you can experiment with this new type of distribution today in the Amazon Appstore with our HTML5 Web App Tester. Simply download the app, point it to your site’s URL and test out how your web app works. From there it’s easy to submit to the Amazon Appstore and begin reaching a whole new audience.

Creating an application using Amazon's Mobile App Distribution Program is a great way for developers who have hosted web apps to create downloadable apps available on the Amazon Appstore. Web app developers benefit from the increased discoverability that the store provides when users are searching for new apps, as well as being reminded to use the web app by the icon on their device's home screen afterwards. In addition, all of a user’s linked devices that use the Amazon Appstore will have the icon waiting in their Cloud list of apps as well.

And because web apps are hosted online, developers have increased flexibility to re-use existing assets and make changes or fixes to the app quickly and easily, without having to re-create a new app that has to be re-installed by the end user. But what happens if the user wants to use the app offline? Obviously, if the app relies on live server-side content - such as streaming videos or airline reservations - then obviously it's not going to work. But if the web app is self-contained and doesn't need to talk to a server for its core functionality - like most games - then being able to take the app offline is something that should be an option for users.

Happily, enabling your web app to be used offline can be done using HTML5's built-in Application Cache with only a few small changes to your code. Below I'll outline the steps you need to take to create a basic offline web app. It's surprisingly easy to set up, but beware! Application Cache has a well deserved reputation for being difficult for developers to get a handle on.

Offline Web App Walkthrough

1. Create Manifest File

The first thing you need to do is create an HTML5 manifest text file with a list of every asset file your web app requires - HTML, JavaScript, CSS, images, icons, fonts, etc. The manifest file can have any name you choose, but we'll use app.appcache to be clear and to avoid overlap with other types of manifest files.

Here's the content of a basic manifest file:

CACHE MANIFEST 
# Version 1.0 
CACHE: 
main.js 
main.css 
logo.png 
NETWORK: 
*

- The first line needs to be CACHE MANIFEST.

- The second line in this example is just a comment, but is useful to make changes to your web app by simply incrementing the version number. Note: Only changes to the manifest file will invalidate the cache.

- The third line begins the CACHE: section where you list out the asset files used by your web app, either relative to the location of the manifest file, an absolute path or complete URL. Note: DO NOT list app.appcache in your manifest.

- The NETWORK: section has a wildcard which permits the browser to download files that are not listed in the CACHE: section. Note: Without the NETWORK: section, the browser will ONLY re-request files listed in the CACHE: section after the initial page load.

2. Confirm Server Settings

You need to also make sure your web server serves the correct MIME type for the manifest file. For Apache, it looks like this:

AddType text/cache-manifest .appcache

You also need to makes sure the manifest file is not being cached on the server. If the HTTP Cache-Control header for the manifest file doesn't update, or a 304 Not Modified is return, then the web engine won't be able to see if the manifest file has been changed or not, which is the only way to invalidate the offline cache.

3. Add Manifest Attribute

You then need to add an attribute to the tag of every HTML page you serve pointing at the manifest file, like this:

<html manifest="app.appcache">

4. Add Update Script

Finally, you need to make sure your app updates itself if the manifest changes - the easiest way to do this is to add this bit of JavaScript to your main HTML:

<script>
window.applicationCache.addEventListener('updateready', function(e){
    window.location.reload();
});
</script>

5. Test

Your web app should now be offline enabled! If you have Python installed, you can test this by setting up a local server to see what's happening both on the server and in the browser.

beattier@amazon.com:~/html5demos/offline$ python -m SimpleHTTPServer

Serving HTTP on 0.0.0.0 port 8000 ...

1.0.0.127 - - [21/Jan/2014 13:42:52] "GET / HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /app.appcache HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.css HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.js HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /logo.png HTTP/1.1" 200 -

... 

1.0.0.127 - - [21/Jan/2014 13:43:12] "GET /app.appcache HTTP/1.1" 304 -

By modifying the manifest file and reloading, you'll see that all the files listed will be re-downloaded again.

You can also connect the Amazon Web App Tester to see the client side of the process as well by using Remote Debugging. (See our previous overview of setting up the Tester here.) In the screenshot above, I've connected to a Kindle Fire HDX and loaded a demo offline web app stored on Github. By looking at the Resources tab and drilling down into the Application Cache folder, I can see the assets that are cached locally, and a log of the Application Cache events.

Application Cache Gotchas

This is just a basic way to setup an offline web app. There are more options that you can add to your manifest file, more events you can track in JavaScript and more functionality you can use to make your web app's offline experience much more seamless to the end user. Check out the links below for more information.

Conceptually, it's important to understand that once you've enabled a manifest, your web app is now offline first and forever. Let's repeat that for clarity: OFFLINE FIRST AND FOREVER.

OFFLINE FIRST means:

- Your web app's files will then always be loaded from the offline cache first, and then a request will be made to the server for the manifest file to see if there have been any updates.

- The browser will not automatically refresh if the manifest has changed. It will in fact download the files from the server, but it will wait until the next time the page is requested to use them. This is why the script in step 4 above to detect a manifest change and immediately refresh the page is important.

FOREVER means:

- The only thing that can invalidate the offline cache and trigger a re-download of files is a change in the contents of the manifest file - not just the timestamp.

- There is no programmatic way to invalidate the offline cache from the browser. Even changing or deleting the manifest attribute in the tag will not invalidate the cache.

- Until the browser requests a manifest and receives a 404 or 410 from the server, it will continue to consider the web app as being offline and use the last downloaded version, rather than updating from the server.

Summary and External Resources

The info above should be able to get you started with offline web apps. Once you've added in the manifest, your web app will be available offline the next time your users load up your app. Fair warning: This can be a tricky feature to implement - especially if you misconfigure or forget some of the steps above. Getting the browser to let go of the manifest and refresh your code can be incredibly frustrating. I think the upside is worth it though, as enabling your web app to be used anywhere a native app can be used is incredibly satisfying.

To get more information about Application Cache, I encourage you to check out these great articles which dive into the topic in even more detail.

·         http://diveintohtml5.info/offline.html

·         http://www.html5rocks.com/en/tutorials/appcache/beginner/

·         http://www.html5rocks.com/en/mobile/workingoffthegrid/

·         http://alistapart.com/article/application-cache-is-a-douchebag

In future posts, I'll expand on offline apps by looking at topics such as offline data storage and efficient caching strategies.

-Russ (@RussB)

Note: Effective 08-26-2015 Free App of the Day (FAD) has been replaced with Amazon Underground.

In August of last year we enabled HTML5 developers to publish hosted web apps next to native Android apps in the Amazon Appstore, making HTML5 web apps discoverable to millions of Amazon customers. Starting today, developers can set a list price for their web apps, giving them another way to monetize web content to Amazon Appstore customers in nearly 200 countries across the globe.

Prior to this update, web apps published to the Amazon Appstore were automatically set to free.  In the latest update developers can now set a list price in specific currencies based on the local markets they’re publishing their web apps to. This is great news for developers looking to publish their first web app to the Amazon Appstore, and the feature is now retroactive to all web apps that have already been published. That means existing developers simply need to log into their Developer Account to see an updated “Availability & Pricing” tab with the option to charge for the app.

Now with the ability to set a price for web apps in the Amazon Appstore, HTML5 developers can take part in our Free App of the Day (FAD) promotion. For developers not familiar with this program, qualifying apps gain greater exposure that could drive significant traffic to their apps. Opting into the FAD promotion and being selected enables us to work directly with the publisher to be featured in some of our most visible marketing placements. This includes placements on mobile devices, Kindle Fire, and the Amazon Gold Box Best Deals page, which are complemented by social media exposure including Facebook and Twitter announcements. These placements and the exposure they provide can drive significant traffic to the featured apps and allow the developers to grow their install base quickly. 

To learn more about qualifying for the Free App of the Day program, check out this post on how to get approved, and make sure you opt to have your web app considered for the program during the app submission process.

To republish an existing app as paid, simply edit the ‘Availability & Pricing’ tab and enter a list price, which is already defaulted to free. The same list price changes can also be made to any submission set to “IN PROGRESS” that is waiting to be approved for release.

This is just one new feature we’ve added to help make publishing HTML5 Web Apps to the Kindle Fire best in class. For more information, check out the HTML5 Web Apps detail page

-Jesse Freeman (@JesseFreeman)

The Amazon Mobile App Distribution Program enables developers to create Kindle Fire apps using existing HTML5 mobile web apps. It’s also a good way for web developers to start creating mobile apps using the skills and knowledge they already have.

Back in December we covered how to get your existing web apps onto actual devices with a Webinar on Submitting HTML5 Web Apps to the Amazon Appstore, and companion blog post focusing on setting up the Amazon Web App Tester to debug and test your apps.

We wanted to follow up with some more details to help you get the most out of the tester, which is a key part of the HTML5 web app creation process on Kindle Fire tablets. The Web App Tester has a variety of powerful features which can be used to make development faster and easier. Below are a few ways to best take advantage of all that great functionality. 

Amazon's Web App Tester

What exactly is Amazon's Web App Tester? It's a downloadable app which lets you test your web app in a production-like environment on your Kindle Fire or Android device, without first submitting it to our store. The tester contains the same web engine and libraries that will run your web app when it is wrapped into a downloadable app. The tester however, has an interface that lets you enter in your own custom URLs, and most importantly, enables remote debugging for development and testing using your desktop computer.

Because the Web App Tester is based on the same technologies as the final wrapped app, you should be able to better assess your app's performance and functionality - and more quickly work through any problems you might encounter - on the device itself, rather than via an emulator or simulator, which may not be as accurate.

Additionally, libraries that are pre-loaded into the final downloadable app, such as the In App Purchasing API for JavaScript, are also built into the Tester so you can debug your IAPs before you launch. (Look for a more detailed post about enabling IAP for your web apps coming soon).   

Managing Multiple URLs

The first thing you'll encounter when using the Web App Tester is a place to enter a URL for testing. This is great for easy ad-hoc testing, but if you have complicated URLs to enter, or have multiple URLs that you need to manage, you can create a JSON file of URLs and put it into the root folder of your Kindle Fire. The file has to be named amazon.testerurls.json and placed in the /mnt/sdcard/ folder on your device. Here's how the list of URLs should be formatted:

{ 
   "urls":[
      "http://m.imdb.com",         
      "http://m.amazon.com",         
      "https://read.amazon.com"]     
}
 

The easiest way to get it to the correct spot on your device is via the command line using the Android Debug Bridge (ADB), which comes as part of the Android SDK. Assuming you've set up the SDK correctly, you only need to connect your device using USB, open a command line, change to the directory where your JSON file is located and run this command:

$ adb push amazon.testerurls.json /mnt/sdcard/ 

Remote Debugging Options

If your device and your computer share the same network, you can enable Web Developer Tools for debugging over WiFi. If you're on a corporate network, or want to test aspects of your app including offline functionality or WLAN speeds, you can connect via USB using ADB.

Helpfully, the Web App Tester gives you all the details you need to enable Remote Debugging once you start the app. Simply click the full screen handle at the bottom or side of the screen, and swipe down. There you'll see options to enable remote debugging using ADB or via your network.

Once you choose, a dialog box pops up with instructions and the exact URL to enter into your Chromium based browser (for debugging). For example, here are the instructions for remote debugging via WiFi:

Close that dialog, enter the URLof your web app to test and you'll be all set to debug via a desktop computer.

Dev Tools Tips

Once the Dev Tools page is open in your desktop browser, remote testing and debugging of your mobile web app should become as familiar as doing development for desktop browsers. Here are some things to watch for.

On Device Tools. First, note that all the normal functionality you'd find in Dev Tools is live, but running on the device itself. In fact the entire UI is a static HTML app served from the device, which then communicates back via Web Sockets. Viewing the network speed, recording the timeline activity or profiling is all happening with the device's hardware.

Reload Shortcut. When doing development for a desktop browser, you may be in the habit of clicking the reload icon in the browser to refresh the page. Rather than exiting out of your app on the device, and then re-starting, you can simply type Command-R/Control-R inside the remote Dev Tools window to refresh the contents of the page on the device itself.

Live Inspection. Just like on a desktop browser, you can use the inspect icon to help pinpoint elements on the screen within the HTML5 markup of your app - rather than clicking the screen, just activate the inspect icon, and then touch the screen to find that element within the Dev Tools. It goes in reverse as well, notice that as you use your mouse to hover over the markup in Dev Tools, the corresponding elements light up on the device.

FPS Meter. In the Dev Tools, you can use the settings icon to turn on the FPS meter, which displays in the top corner of your device. This will let you get a live view of how fast your app is refreshing, without having to add in additional libraries.

On Device Debugging and Console. You can step through JavaScript code just as you would normally. Additionally, the console is also live, with the JavaScript engine running on the device. This allows you to use console tricks such as $0 to refer to the selected element, navigate using document.location.href, or even pop up an alert() window if needed.

Remote Debugging API

Because the Web App Tester's Dev Tools use the same remote debugging protocol as desktop Chromium browsers, they can be accessed not only from Dev Tools, but from text editors, IDEs or via scripting languages such as Python. Here's an example using the chrome-remote-interface Node.js module.

First, install the library using NPM:

npm install chrome-remote-interface 

Then create a test.js file with this boilerplate example (modifying the options variable as needed):

var Chrome = require('chrome-remote-interface');

var options = {

host:  'localhost',

port:  '9222'

};

Chrome(options, function (chrome) {

    with (chrome) {

        on('Network.responseReceived', function (message) {

            console.log(message);

        });

        on('Page.loadEventFired', function (message) {

            console.log("----------------------- page loaded ");

            console.log(message);

        });

        Network.enable();

        Page.enable();

        Page.reload();

    }

}).on('error', function (err) {

    console.log(err);

    console.error('Cannot connect to Chrome');

)};

Then run the script

node test.js 

As you use your app on the device, you'll see events logged in your console as they fire. The protocol and module will also let you send commands to the remote browser, letting you automate testing on the device and recording the results. For more info, check out the Remote Debugging Protocol pages here.

Hopefully some of these tips will come in handy as you're doing development for your web app, if you have any tips of your own or questions about using Dev Tools, definitely get in touch!

-Russ (@RussB)

HTML5 Web Apps: Tips on Acquiring Customers in the Amazon Appstore

We want to start the year off by focusing on getting your Web Apps noticed in the Amazon Appstore, so you have the best chance of acquiring new customers.  There are a few easy steps you can take to so that your apps, whether web or non-web apps, are more appealing to first time downloaders.  This includes ensuring you have quality screenshots and promotional images, detailed product descriptions, an easy way for customers to review or share your app, as well as a way for customers to discover your apps outside of the Amazon Appstore.  Amazon also offers unique ways to help your Web Apps get noticed including weekly promotions for the top Web Apps in the Appstore as well as access to Appstore Developer Select.   

Appstore Developer Select

All Web Apps submitted to the Amazon Appstore will be automatically entered into for Appstore Developer Select, if they meet the program requirements.  This program helps get your Web Apps discovered and gives you more opportunities to boost your sales and revenue.  As a developer with one or more qualifying apps, you will receive the following benefits:

• Enhanced Merchandising to Improve Discovery: Your qualifying apps will receive 500,000 free mobile ad impressions across the Amazon Mobile Ad Network. We’ll provide enhanced merchandising for your apps in a dedicated section on the Amazon Appstore home page and consider your apps for advertising on Kindle Fire.
• Amazon Coins Rewards to Customers to Improve Conversion: Consumers purchasing your app or in-app items in your app will receive up to 30% of the purchase price back in Amazon Coins. We’ll boost customer acquisition by rewarding first-time purchasers of Select paid apps and in-app items with an extra 250 bonus Coins.
• 25% off AWS Services to Help You Scale: You will earn 25% credit back on qualifying purchases of Amazon Web Services (AWS) products, up to a maximum $500 credit per year.

You can check the status of your eligibility by going to the My Apps section of the Apps and Services Tab in the Developer Console.
 

You can click on View Report to see which items your App has passed on and which items you need to update in order to become eligible.

Once your app has been enrolled in Appstore Developer Select you will also have the option to view the Ad Campaign that has been set up on your behalf.
 

Optimizing App Details

The title and description of your app is like the front door of a building.  Customers will never know what’s inside until they knock and walk inside.  By writing an effective description you can change your app from the spooky abandoned house on the corner to an enticing new shopping mall just waiting to be explored.

The keywords section will be how customers find your app when searching the Amazon Appstore so make sure you chose relevant discoverability terms. 

In addition to the App details you can also select a Content Rating for your app letting customers know what to expect.

Be sure to read our previous blog post with tips on effective title and description for your apps here.

High Res Screenshots and Multimedia

Your Web App submission will need to provide screenshots of your app running as well as an optional video.  You should create and upload both a 114x114 icon and a 512x512 icon, which will be used for the app list and carousel respectively.

In order to take the screenshots of your app running you will need to use the Web App Tester program on a Kindle device (emulators are not currently supported) and use the Kindle built in screenshot button combination.  The button sequence for each Kindle device can be found here.

You will need to next copy the screenshots off of the Kindle device and uploaded to the developer portal.  

On windows simply plug in your Kindle device and open File Explorer to Internal Storage > Pictures > Screenshots.

For Mac OSX you will need to use the Android File Transfer Tool and navigate to Pictures > Screenshots.

While you are only required to submit three screenshots, having additional screenshots as well as a promotional image is recommended and will help to increase the chance for downloads.  You can also include an optional Video showcasing your Web App.

You can get additional information on taking screenshots of your Web Apps via the official developer documentation  here.

App Badges

Amazon also offers App Badges you can include on your Website and customer communications such as email blasts.

These Badges are available in a variety of languages and will further increase potential download traffic to your app by referring customers who are already interested in your products or have come across your website. 

For full details on using App Badges be sure to check out the documentation here.

Conclusion

Building an audience for your apps and connecting with new customers is an important concern for most developers.  By following the steps listed here you can ensure a higher chance of getting noticed.  The more customers who see your app the greater the chance of increased downloads, more reviews and eventual promotion inside the Amazon Appstore.

Got a great HTML5 Web App in the Amazon Appstore?  Looking to get promoted?  Why not tell us about it!  You can Contact Us directly and let us know. 

-Dave (@TheDaveDev)

Starting today all Web App submissions to the Amazon Appstore now support Amazon Device Targeting.   While it is possible to detect and optimize your mobile websites server side, you may decide you only want to target your Web Apps to specific devices.  Web App submissions to the Amazon Appstore now allow the same device targeting capabilities that Android submissions do.  This means you can elect to make your Web Apps available for download on Kindle Fire, Kindle Fire HD, Kindle Fire HDX, general Android (all non-Amazon) devices or any combination of these.  

By enabling device targeting within your individual Web Apps you can tailor your app experience to the specific screen size, density, and capabilities of Kindle devices.  For example, you may decide to target only devices capable of the Amazon Webview (Kindle Fire 2^nd generation and up) giving your Web Apps native-like speeds on Kindle devices.

What has changed?

In the previous version of the developer portal you did not have the option of choosing the device on which devices your Web Apps would be available.  By default your Web Apps would run on all Kindle Fire devices as well as Android capable devices. 

As of today, a new Device Support section has been added that will allow you to target any or all of Web App capable devices you choose.

Enabling Device Targeting

To enable Device Targeting in your Web Apps simply navigate to the Apps and Services, My Apps section in the developer portal, click on the title of your Web App, and then select the App File(s) tab.

You can then select the individual devices you want to target.  By default we will enable all Web App capable devices so be sure to uncheck any devices you specifically do not want to support.  Once you click the Save button you will find a new list of all the devices you have selected to support.

That’s it!  By following these few steps you now have more control over which devices your Web Apps will run on, giving you the option to tailor your app experience to the capabilities of each device.

-Dave (@TheDaveDev)

The Amazon Mobile App Distribution program enables you to distribute your existing web apps on Kindle Fire and select Android devices in nearly 200 countries across the globe (including the US, Canada, UK, Germany, Spain, Italy, France, Brazil and Japan). 

Almost any mobile friendly website you are hosting today can be run as a Web App.  This means all of the HTML5, JavaScript, and CSS code you have built today can be made available as an App in the Amazon Appstore. 

In the recent Webinar on Submitting HTML5 Web Apps to the Amazon Appstore, we covered how to get your existing web apps onto actual devices and debug and test them.

You can debug your HTML5 Web App in two different ways.

•      You can use your favorite IDE or debugging tools for normal Web App development like you are already doing. 

•      Or, you can optionally use the Chrome DevTools to debug your web app using a Kindle Fire or an Android device running the Web App Tester Tool.

Note: The Chrome DevTools, the Chrome Browser installation tool, the Android SDK and certain other development tools are provided by third parties, not by Amazon.

Setting up your Debug Environment

The Chrome Developer Tools are freely available from Google and included in all the latest versions of the Chrome Browser.  Simply select the Chrome menu at the top-right of your browser window, then select Tools > Developer tools to begin debugging.  You can get additional information on installing the tools off the Chromium blog.  The Chrome DevTools use the Android Debug Bridge (adb), part of the Android SDK tools, to communicate with the web app from your computer.

Next, we will need to install the Web App Tester Tool from the Amazon Appstore.  This tool will allow us to create a bridge to our computer over USB or WiFi. 

Simply swipe from the top of the device (if on a Kindle Fire device make sure you tap the full screen handle on the bottom of the screen to open the status bar) and then swipe down from the top of the screen to display the Quick Settings Notification Area.  Once there you will have the option to connect over either USB or WiFI.

In this example I have selected WiFi and am given a url I can put into my browser to connect the Chrome Dev Tools to that running app.

Here is a screenshot of a Kindle Fire running my Web App with the Chrome Debug Tools showing the source for my app.  This enables me to now select actual <div> tags now in the html code via Chrome on my computer and see those <div> tags being highlighted on my actual device (as in the example below).

Conclusion

By utilizing the free Chrome Developer Tools and the free Web App Tester tool we are now able to debug our Web App on an actual device in real time.  This includes everything you would expect from the Chrome Developer Tools, like real time resource monitoring, the ability to view our html source and a JavaScript console.

For a complete walkthrough of the steps described here you can watch the short screencast below as well as checking out the web app debug documentation on our developer portal here.

-Dave (@TheDaveDev)

Today we have a video interview with the executive leadership of Tre Sensa (http://www.tresensa.com/) a NYC based game development and distribution company that optimizes games for the mobile web. In this video, they talk about their business and the importance of HTML5 in their goal to deliver apps to as many screens as possible. They also discuss their experience developing HTML5 apps for Amazon mobile devices as well as a talk about how they came to use Amazon Web Services to support their mobile gaming applications. 

We hope you enjoy this video interview with TreSensa. 

Ever wonder what’s involved in turning your web app into an app you can launch from a mobile device? On the Amazon Appstore, it’s pretty easy, and involves just a few steps you can learn about here. One of those steps is adding a JSON file called the web-app-manifest to your web app.

This manifest file contains information required to run your app on a mobile device, and the basic manifest file is created for you on the developer portal. Where you put that manifest file can make a difference though. You should know about that and how to edit your manifest file in order to give your app access to features like geolocation on the device.

Where can you put the Manifest, and what difference that makes.

While we recommend that you put the manifest file at the root of your web app, you can put the manifest file anywhere on your server. The location of your manifest file determines what pages will render in the context of your app, and which pages will render in the default browser. The pages in the sub-domains under your manifest will be accessible by your app and will render in the context of your app. Any pages outside of those domains or directories will open in the default browser instead of in the context of your app.

Take a look at what pages will and won’t be accessible from your mobile app depending on where you put the manifest. Note the special case of www. and m. addresses in yellow below.

SSL Note:

• If the manifest is delivered with https://, then the entire app must be delivered over SSL as well.
• If the manifest is delivered with http://, the app may be still be served over SSL.
• If you use any permissions (IAP, Geo Location, Login), you must use SSL.

Now that you have a good idea where to put your manifest, what to put in it?

Contents of the web-app-manifest.json file

The manifest created automatically for you will look like this:

{
 "verification_key" : "c8efxxxx-xxxx-xxxx-xxxx-xxxxe5b239e9",
 "version" : "0.00(0)",
 "type" : "web",
 "last_update" : "2013-11-19 23:40:17+0000"
}

• “verification key” connects your website to your app.
  *This is the only required field in the manifest.

• “version” helps you track the version that you have submitted
• “type” lets us know that in this case, the app is a web-app
• “last_update” is when this manifest file was created (you can change it to match your updates)

In addition to the elements above, you may also wish to add one of these elements:

• “permissions” specifies the permissions your app will request (these will require SSL use).  They consist of:
• “Created_by” = you.
• “launch_path” identifies the file you want your app to open

1. iap = In App Purchasing
2. geolocation = Get location information
3. auth = if you request user credentials for login (facebook connect, google, your own.)

A finished web-app-manifest.JSON that uses all available fields might look like this:

Updating your web-app-manifest.JSON file

If after your app launches, you decide you want to update you web-app-manifest.JSON file, the app on device will not automatically update with new JSON file data. You will need to publish an updated version of your app. You can create an updated version of your native app in the dev portal by using the ‘Add an upcoming version’ link at the top of the developer portal page for your app (see below).

Once your new version submission is underway, you can submit and verify a new manifest, and then submit the new app version for publication.

A Tip to Remember!

Please be sure to configure your server to accommodate .JSON MIME types! For example:

.json -> application/json
.webapp -> application/x-web-app-manifest+json

More Information

You can find detailed documentation on the web-app-manifest.JSON file and on HTML5 app submission on our Dev Portal here.

Should you have any additional questions about the web app manifest file and how it is used, please send us a quick note so we can get you the answer you need.