Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts

Archive

July 19, 2012

Amazon Mobile App Distribution Program

Meet Amazon at Casual Connect Seattle from July 24-26!

Happy Hour at the Diller Room- July 24, 2012 6:00-8:00 PM

Join us for drinks (two drink tickets provided) and hors d' oeuvres at the Diller Room on July 24th from 6pm-8pm. Mingle with representatives from the AWS, Amazon Mobile App Distribution, and GameCircle teams and enter a drawing to win a Kindle Fire.

You can register for the Happy Hour event on this page or just simply drop by. Please remember to bring your Casual Connect Conference badge for admittance.

The Diller Room is located at 1224 1st Avenue, Seattle, WA 98101.  The location is one block west of Benaroya Hall on the corner of 1st and University.

Amazon Speaker Sessions at Casual Connect

 Join us for two conference sessions hosted by Amazon speakers:

  • Monetization Trends for Mobile Games with Aaron Rubenson, Director, Amazon Appstore for Android- Wednesday, July 25 at 10 AM.
  • Optimizing Games for Kindle Fire with CJ Frost, Developer Evangelist- Thursday, July 26 at 11:30 AM.

Amazon Tables at Casual Connect

While you are at the Casual Connect conference, please stop by our tables - #B29 and #B30. We'll be at the tables from 8AM-6PM.

July 17, 2012

Amazon Mobile App Distribution Program

Kindle Fire development resources are now available to our developer community! These resources provide detailed documentation, best practices, an emulator, and sample code to make it easy for you to build great applications for Kindle Fire customers.

Our documentation details how to set up your development environment, create a great customer experience, and optimize and test your apps for Kindle Fire. We also provide a Kindle Fire emulator to help you more easily lay out and test your apps, and sample code that illustrates our best practices for performing specific tasks.

It’s easy to get started building and optimizing your apps for Kindle Fire. Visit the Kindle Fire Development Resources page on the Distribution Portal and start building today!

July 16, 2012

lisamar

The distribution portal is now available to developers looking to sell their apps outside of the U.S. Apps will be made available for distribution in the United Kingdom, Germany, France, Italy, and Spain later this summer, with plans for further global expansion in the future. To prepare for this expansion, developers can now localize their apps by adding marketplace-specific pricing as well as language translations for your apps, in-app purchasable (IAP) items and subscriptions. We’ve also updated the design of the distribution portal, and optimized it to improve your experience when adding, updating, and reporting on your apps, IAP items and subscriptions. This post provides an overview of the steps to localize your app within the Distribution Portal. 

Updating Your App Metadata

1. Within the distribution portal, choose the app that you want to edit and click on the app.

    Image_1

    2.  Confirm the countries where you’d like your apps to be made available by clicking on the Availability and Pricing tab in My Apps. This tab also lets you set list prices by marketplace. Developers allowing Amazon to sell apps internationally are responsible for ensuring their apps comply with all applicable export and import restrictions and the laws of the countries in which the apps are sold.

      Image_2

      3. Set the list price for each marketplace by setting the base list price and the currency of the list price. Unlike the U.S., the list prices that you set for each E.U. marketplace should be your suggested price inclusive of any VAT or similar taxes. These taxes are deducted from the list price when calculating royalties. If you do not set unique list prices for each marketplace, Amazon will calculate the list prices for you based on current exchange rates.

        Image_3

        4. Provide translated descriptions for app detail pages by navigating to the Description tab, editing the English (U.S.) description, and then choosing the option to add a new language. Languages available include English (U.K.), German, French, Italian and Spanish. You will be able to add language translations for the app title, short and long description, keywords, and product feature bullets.

          Image_4

          5. You will be able to go back and edit any of the above until you hit submit. Once you submit your app, it will be in the review state, and you will not be able to edit your app.

            Updating In-App Items and Subscriptions

            First find the related app, and then navigate to the IAP items or subscriptions. Follow the same process for setting availability, list prices and description.

            Image_5

            Image_6

            Updating Your Binary File

            1. From within the app you want to edit, click the Add Upcoming Version link.

              Image_7

              2. Within the Binary tab, you can now select the locales which you support. You can display localized versions of any string in your app or any sound or graphic by leveraging localization best practices and using resource files to provide the appropriate translation or asset. If you have already provided an APK that supports multiple languages, you will not need to take any action.

                Image_8

                3. You will be able to go back and edit any of the above until you hit submit. Once you submit your app, it will be in the review state, and you will not be able to edit your app.

                  With the launch of app availability in new countries, our reporting will split sales, earnings, and payments by marketplace. In addition, new payment reporting will enable you to track when a payment was made and the amount by marketplace.

                  For more information on international distribution, read our FAQs.

                  July 12, 2012

                  Amazon Mobile App Distribution Program

                  Glu_Mobile_promoImages

                  Founded in San Francisco in 2001, Glu Mobile is a mobile games publisher for smartphone and tablet devices boasting titles such as Blood & Glory, Frontline Commando, Contract Killer, Big Time Gangsta, Bug Village, Eternity Warriors, and Gun Bros. They also have new games launching regularly and recently launched their casual hit title, STARDOM: THE A-LIST. In addition to participating in the Free App of the Day program, Glu was part of Amazon’s In-App Purchasing beta program. Mike DeLaet, VP of Global Sales & Marketing, remarked on their experience:

                  What drove you to participate in the beta test for the Amazon SDK and In-App Purchasing API?

                  Glu offers freemium mobile means – which means that they are free to download and play with the additional opportunity for users to purchase in-game virtual goods to improve the gaming experience.  Amazon’s in-app purchasing functionality was a perfect fit for Glu and the type of games that we offer.

                  What types of monetization do you use (e.g., ads, in-app purchasing, subscriptions, upgrades)?

                  The majority of our games monetize through the use of in-app purchasing, though we do provide regular updates and upgrades to our games. 

                  How did you come to the decision to monetize your apps?

                  Glu decided in early 2010 to focus our efforts on creating high quality, high production value freemium games.   We set out to provide users with the best experience possible, while making our games free to download and play.  Because we were confident that users would find our games fun and engaging after downloading, we believed that they would be willing to spend money to enhance the gameplay experience.  However, users aren’t required to spend money if they choose not to.    

                  How has your experience with Amazon compared to your expectations and/or experiences with other Android marketplaces?

                  Our experience with Amazon thus far has been great.  Amazon as a company truly understands effective merchandising and has an enormous user-base with which to cross-promote.  We look forward to seeing how our business develops over the coming months and years with Amazon.

                  What advice do you have for other developers?  Any tips for how developers can leverage in-app purchasing to grow their businesses?

                  Every game is different, so analyze the results of your game and make sure you are providing what the customer wants. One of the most basic things we look at is what our customers are buying and what they are not buying within each game.  This helps us create more of what people want versus what they don’t and we can keep our stores filled with the right content. Building a freemium game is a constant iterative process. The best monetizing games require you to be fully committed!  

                  Have you received customer feedback on the Amazon experience?   

                  We keep a close eye on customer reviews for all of Glu’s games on the Amazon Appstore and so far they are excellent.  One of our recent releases, Blood & Glory, has over 7,000 five-star reviews and our other freemium titles are showing similar results.  This is proof to us that we are creating fun, engaging games that people enjoy playing.

                  July 10, 2012

                  Amazon Mobile App Distribution Program

                  Announcing Amazon GameCircle, a new set of services designed to make it easier for you to create more engaging gaming experiences and grow your business on Kindle Fire. GameCircle will make achievements, leaderboards and sync APIs accessible, simple and quick for you to integrate, and will give gamers a more seamless and entertaining in-game experience.

                  Game developers can sign up for access to the GameCircle APIs here: https://developer.amazon.com/sdk/gamecircle.html. Game players can find Kindle Fire games that are now using GameCircle services here: http://amazon.com/gamecircle-games.

                  Achievements

                  GameCircle achievements allow players to track all earned trophies, treasures, badges, awards, and more without leaving the gaming experience. Players can receive in-game messages to keep track of accolades earned in real-time or pause and view an achievements summary to check earned collections and determine what badges are still needed, before returning to gameplay.

                  Leaderboards

                   

                  GameCircle leaderboards provide an in-game view of score comparison information and percentile ranking, allowing players to quickly and easily check standings against top players or competitors, without ever leaving your game.

                     

                  Sync

                   

                  Sync automatically saves a player’s in-game progress to the cloud and allows them to pick-up exactly where they left off when restoring a deleted game or switching devices. Players will not have to worry about losing progress, scores or achievements between Kindle Fire devices, as all data is securely stored in the cloud. [Note: Sync to cloud functionality requires a game to integrate the Sync API.]

                  “Our goal is to give developers great tools to quickly and easily reach new customers and keep them engaged. That’s why we’re creating easy-to-integrate APIs for features like leaderboards, achievements and sync.  We also introduced In-App Purchasing API in April, allowing developers to offer a seamless 1-Click purchasing experience within their apps and games, and we’re just getting started,” said Paul Ryder, Vice President of Apps, Games, and Services at Amazon. “GameCircle gives developers the right tools to build an immersive, more entertaining experience on Kindle Fire, which will ultimately help developers grow their business.”

                  What do our beta program partners say about GameCircle services?

                  “We are thrilled to be part of Amazon’s GameCircle with Temple Run,” said Keith Shepherd, Co-founder of Imangi Studios. “The new service is a great way to keep our fans engaged by offering them more opportunities to play the game, and an intuitive platform to connect with new players.”

                  "Sync is a wonderful addition to Triple Town,” said David J Edery, CEO of Spry Fox. “It guarantees that Kindle Fire users will not lose their active game or their hard-earned coins if they replace their Fire, or if they must uninstall and reinstall Triple Town for whatever reason. It also enables multiple-device owners to transfer their game from one device to another—something we think gamers will love." 

                  "We’re excited about Amazon’s new Game Services because it brings a new level of engagement for our most popular Android titles such as Doodle Jump and Collapse!,” said Ken Murphy, VP of GameHouse Studios. “The ability to compete for high scores and achievements through the Amazon network means even more fun for GameHouse players.”

                  Game developers can sign up for access to the GameCircle APIs by visiting: https://developer.amazon.com/sdk/gamecircle.html

                  Game players can find Kinde Fire games that are now using GameCircle services here: http://amazon.com/gamecircle-games

                  July 08, 2012

                  Amazon Mobile App Distribution Program

                  With the launch of the Amazon Mobile App Distribution Portal for international distribution, we'd like to talk about how to get your Android apps ready for an international audience.

                  Localization is the process of making your app display appropriate resources depending on the device's default locale and language. "Appropriate Resources" can include more than text. Depending on your app, you may also want to change:

                  • Number and date formatting
                  • Currency formatting
                  • Colors and layout styles
                  • Input methods

                  Localization is a big topic, so we'll focus on those resources that impact customers the most: text, images, and currency.

                  Each Android device has a default locale which consists of a region and language, which you can query programmatically. Fortunately, this is seldom necessary. Since Android is designed to be used on a variety of platforms, it looks for resources that are appropriate for the current execution environment. For example, you may already provide different bitmaps or backgrounds for your app based on the device's pixel density. As long as the resources are in the right directory (e.g., drawable-hdpi), Android will select the best resource for the job.

                  Localization works the same way – by putting your resources in the correct folder, Android will find the right one at runtime, without you having to write additional code. The simplest example is one you are probably familiar with: /res/values/strings.xml. The strings.xml file is designed to hold your user-viewable strings in such a way that they can be used by reference. Here is a sample definition in strings.xml:

                   <?xml version="1.0" encoding="utf-8"?>

                  <resources>

                    <string name="hello">Hello!</string>

                  </resources>

                  The string resource named "hello" can be referenced in your source code by calling:

                  String helloText = getString(R.id.hello);

                  And in other XML files (such as layout or the manifest) by referencing:

                  <application android:label="@string/hello" >

                  Now suppose you want to provide a better user experience for new customers who speak French or German. Simply create a new version of strings.xml for each language, and put them in their own "values" directory. The format is: values-xx-rYY, where 'xx' is the ISO-639 language code, and 'YY' is the ISO-3166-1 region code.

                  /res

                        /values     (default directory, make sure all references are present)

                        /values-fr  (contains French language strings, region not used)

                        /values-de  (contains German language strings, region not used)

                  When Android looks for a string reference, it will try to match a resource that is specific to a region and language, then by language, then in the default directory (values). It is extremely important to make sure all of your string references are in the default directory.

                  If Android fails to find a reference after searching the default directory, your program will force close!


                  Once the references are defined in the defaults, your language-specific files can define the strings you want to localize in that language. For example, some language speakers are comfortable with a mix of English and their native tongue, while others speakers expect a full translation.

                  Not all UI presentation is done using strings, and many apps have menus, price lists, or instructions written as bitmaps or other graphical data. Fortunately, the same dynamic resource handling we just saw with strings applies to resources in the drawable folders as well.

                  /res

                        /drawable

                        /drawable-fr      (contains German language strings, region not used)

                        /drawable-de      (contains German language strings, region not used)

                  If you already have several drawable directories with resources based on pixel density, you can further extend the structure to accommodate language. The resource directory name modifiers (locale, pixel density, screen size, screen orientation, etc.) can be chained together:

                        /drawable-fr-ldpi

                        /drawable-fr-mdpi

                  If you find yourself reusing drawable assets (putting duplicate copies of bitmaps in several folders, for example), Android provides a way to "link" a reference to a binary using an XML file in the drawable directory.

                  Suppose you want the resource named "background" in the Great Britain locale to point to a resource in the default drawable directory. Save the following file as "/drawable-en-rGB/background.xml":

                  <?xml version="1.0" encoding="utf-8"?>

                          <bitmap xmlns:android="http://schemas.android.com/apk/res/android"

                          android:src="@drawable/background_common" />

                  Any reference to "background" that resolved to that directory (drawable-en-GB) would automatically use the resource: /drawable/background_common.

                  Lastly, we'll look at an example where we display the price of our IAP items in local format. The most important elements are the currency symbol, and the decimal divider:

                  €19,95                   // in some European locales

                  $19.95                   // in North America

                  Let's say your app uses the IAP API to fetch a price for an item from the regional store. The API will give you a price that you can parse to a float. Wouldn't it be nice to have an object that takes care of the number formatting for you? As it turns out, Android provides a NumberFormat object for this purpose.

                  To get the formatted String, make the following calls:

                  NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.getDefault());

                         String formattedPrice = nf.format(19.99f);

                  This is formatting only, and does not do currency value conversion. If you decide to use a locale other than the default, make sure you define it using both language and region (e.g., en_US, or fr_FR). Otherwise you won't get the correct formatting. For example, there are many countries using French as their primary language and have different currencies.

                  As mentioned before, localization is a deep topic – we've barely scratched the surface. Check back for additional tips to improve the customer experience as you distribute your apps around the world.

                  June 28, 2012

                  Amazon Mobile App Distribution Program

                   Jeff Hines, Kindle Fire test team, and Chirag Mehta, a2z Developer Center Inc., an Amazon.com company, are our bloggers for this post.

                  This fourth post in our Top 10 App Optimizations for Kindle Fire series involves optimizations that allow for successful installation on Kindle Fire.

                  While all too common, installation failures are easily preventable. Rather than by coding errors, installation failures result from a misunderstanding of the device software, features, and capabilities. This post contains helpful optimizations that address prominent issues preventing installation on Kindle Fire.

                  What version of the Android platform does Kindle Fire utilize?

                  When developing an app exclusively for Kindle Fire, ensure that your app is developed using the correct Software Development Kit (SDK) version. Many apps fail to install because they were developed to operate within a different version of the Android SDK platform.

                  If your app requires a different SDK version than what is used by Kindle Fire, then you will see an error similar to the following:

                  “…Could not parse package (at Binary XML file line #11): Requires newer sdk version #13 (current version is #10)”

                  To properly optimize your app for Kindle Fire, you should specifically target Android 2.3.4 - API Level 10.

                  If you have designed your app to install on Kindle Fire and multiple devices running other versions of the Android SDK, simply adjust the minimum Android Program Interface (API) Level within your manifest:

                  <uses-sdk android:minSdkVersion="10"
                            android:targetSdkVersion="13" />

                  Be aware that you can set the maximum API value by utilizing android:maxSdkVersion=”X”. However, we do not recommend blocking installation on future versions of the Android SDK, as all newer versions of the platform are backwards compatible.

                  If you intend to have your app exclusive to Kindle Fire, then you may simply equalize the minimum and target values:

                  <uses-sdk android:minSdkVersion="10"
                            android:targetSdkVersion="10" />

                   

                  For more information on declaring API values within your manifest, visit http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

                  Kindle Fire and Google Mobile Services (GMS)

                  If you have packaged your app using Google Mobile Services (GMS) such as the Google Maps library, then your app will not install on Kindle Fire. Unlike some other Android devices, GMS are not present on Kindle Fire.

                  When trying to install an app that requires GMS, you may encounter the following error:

                  “…requires unavailable shared library com.google.android.maps; failing!”

                  While the Google Maps library is not present on the Kindle Fire, you may still connect to Google Maps via Wi-Fi. Otherwise, if your app must have offline mapping, then we recommend developing your app to utilize an alternative mapping service. 

                  If your app is fully functional without GMS support, we recommend disabling the service entirely by removing the line of code from the manifest that links to the library.

                  Depending on your app’s functionality, you may also need to modify your mapping features to gracefully degrade (e.g., with an error message such as “This feature is not currently available on this device”). If you plan to implement an alternate mapping service in an updated version, then you might use a message such as, “This feature is not currently available at this time.”

                  Be aware that if your app also uses in-app purchasing technology powered by Google Mobile Services, this functionality will not work on Kindle Fire. Amazon now directly offers an alternative In-App Purchasing API that allows easy access to purchasable digital content and subscriptions. Please refer to our In-App Purchasing section of the Developer FAQ for more information.

                  Continue to check back in for our next post in this series which will cover optimizations that target graphical performance on Kindle Fire.

                  June 27, 2012

                  Amazon Mobile App Distribution Program

                  Brett Taylor, Principal Product Manager, Amazon Web Services, and David Lane, Principal of Business Development, Amazon Kindle, are our guest bloggers for this post.

                  With its unique “split browser” architecture, the Amazon Silk web browser builds upon the power and capabilities of the Amazon Web Services (AWS) cloud to fundamentally rethink the level of performance and functionality that a browser can provide. Since the Kindle Fire launched, in late 2011, Silk has consistently been one of the most popular device applications. As web traffic originating from Silk continues to grow, many site owners have asked for guidance on how to ensure a great customer experience in our browser.

                  This post lists a few of the more common questions we’ve received from site owners and the prescriptive guidance that we’ve shared with them. If you have additional questions that we haven’t addressed, we encourage you to submit them here. We’ll continue to monitor your inquiries and post updates as needed.

                   

                  1.       What is the Amazon Silk user agent string?

                  Amazon Silk will supply one of two user agent strings in the request headers. The first is referred to as the “desktop” user agent. This user agent string indicates that the browser is requesting the standard desktop version of the page.

                  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/[browser version]) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=[true or false]

                  The second user agent is referred to as the “mobile” user agent. This user agent string indicates that the browser is requesting the mobile view of the web page.

                  Mozilla/5.0 (Linux; U; Android Android version; Silk/[browser version]) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Silk-Accelerated=[true or false]

                  The browser version section of the user agent string will change with each new version of the Amazon Silk browser.

                  The Silk-Accelerated parameter will be set to either true or false. If it is set to “false,” the request is being made directly to origin (i.e., it has not been routed through the Amazon Silk EC2 backend). If this parameter is set to “true,” the request may be routed through the Amazon Silk EC2 backend.

                  2.       What is the client’s IP address?

                  In cases where the Silk-Accelerated parameter is set to “false,” the source IP address of the request can be obtained as it normally would be on any HTTP request.

                  However, in cases where the Silk-Accelerated parameter is set to “true,” the source IP address of the request will be the IP address of the Amazon Silk EC2 backend server. In this case the source IP address of the end client is supplied in the x-forwarded-for request header.

                  Please be aware that each request from a single end user may be routed through different EC2 servers. In other words a web site may receive a series of requests from different source IP addresses but with the same x-forwarded-for header.

                  Additionally, a single Amazon Silk EC2 backend server will support multiple end users. This means that a web site may see requests with the same source IP address but different x-forwarded-for headers.

                   

                  3.       Does Amazon Silk support the Adobe Flash plug-in?

                  Version 10.3 of the Adobe Flash plug-in comes preinstalled on the Amazon Silk browser. In the most recent version of Amazon Silk (v 1.0.13.81) the Adobe Flash plug-in was disabled by default. Users can enable the plug-in by selecting the “Enable Flash” option in the browser settings menu.

                  Amazon Silk version numbers where Flash was enabled by default contain a hyphen. Version numbers with no hyphen have Flash disabled by default.

                  Web developers who wish to present Flash content to Amazon Silk users should check whether the Flash plug-in is enabled. If it is, Flash content can be safely presented to the user. If Flash is not enabled, the web developer should either present alternate content to the user (much like they would to iPad users) or present a message asking the user to enable the Flash plug-in in the settings menu.

                  Given Adobe’s announcement that it will discontinue support for the Flash plug-in on mobile devices, we are recommending that site owners transition to HTML5 video. Below are a set of steps to help solve for this issue going forward:

                  As part of website optimizations for Kindle devices and the Silk Browser, we are recommending a set of steps to help solve for non-Flash video playback.

                  • Ideally, your site would detect whether or not Flash is available on the device
                  • As a fallback, you can look for the Silk user agent (details above)
                    • When Silk is detected, use an HMTL5 video playback element rather than Flash video
                  • If HMTL5 video is not available, suppress the “Download the latest Flash player message” as this intent is unavailable to Silk customers on Kindle LCD devices

                  4.       How can web developers optimize site performance for Amazon Silk users?

                  There are several techniques web developers can use to optimize the performance of their web sites for Amazon Silk users.

                  Caching on the Amazon Silk EC2 backend is one of the primary mechanisms Silk uses to accelerate page loading. Silk’s backend will only cache page elements that are explicitly marked as cacheable by the web developer. Web developers can assure that their web sites are optimized to take advantage of this caching by explicitly setting at least one of the following HTTP cache-control headers: max-age, expires, and public. The longer the time-to-live for a cacheable element the more benefit Silk users will receive.

                  Another important consideration in web page design is to explicitly set the height and width attributes on any elements used in the page (e.g., images). The Amazon Silk EC2 backend will optimize the delivery of the page elements using the height and width. This optimization will improve page latency for the user and minimize bandwidth usage.

                  For additional, more general, information on the Amazon Silk web browser, visit the Amazon Silk FAQs.

                  June 19, 2012

                  Amazon Mobile App Distribution Program

                  We’re pleased to announce that you can now submit apps for distribution in the United Kingdom, Germany, France, Italy, and Spain, using the Amazon Mobile App Distribution Portal. We’ll begin distributing apps in these countries later this summer (and we have more countries planned in the near future). 

                  The Amazon Appstore in the U.S. has had a very successful year with millions of customers discovering and downloading apps and games. We continue to welcome new developers onto our platform, and since launch, we’ve grown to tens of thousands of apps—with more coming every day. Our recently launched In-App Purchasing API is already helping developers like Mobile Deluxe, G5 Entertainment, and Social Gaming Network delight their customers and generate significant revenue. Amazon now offers developers the opportunity to experience similar success with app sales outside the U.S.

                  Now is a great time for new developers to sign up and become familiar with the program. You have the ability to select the countries where you would like your apps to be sold and set your list prices by marketplace. If you are already participating in the program, your apps will automatically be made available for sale internationally by default. And you can easily change international availability for your apps via the Distribution Portal if your apps should not be sold in select countries. Developers allowing Amazon to sell apps internationally are responsible for ensuring their apps comply with all applicable export and import restrictions and the laws of the countries in which the apps are sold.

                  Though Amazon will not require apps to support multiple languages, we encourage you to consider localizing your apps with language translations and to think of creative ways to deliver great experiences to your international customers. Just as in the U.S., if you sell apps in the U.K., Germany, France, Italy, and Spain, you will benefit from Amazon’s trusted 1-Click purchasing as well as the easy-to-integrate In-App Purchasing API.

                  Today we are also announcing two changes to the Amazon Mobile App Distribution agreement. First, building on the success of the April In-App Purchasing Service launch, and to simplify our global terms, Amazon will be aligning the revenue share for paid apps with that for in-app products sold using Amazon’s In-App Purchasing Service. Starting July 1, you will earn 70% of list price on each paid app sale. This is a change from the prior terms under which you earned either 70% of the app’s sales price or 20% of list price (whichever was greater). To put it differently, starting in July, you’ll receive 70% of the list price for all sales, regardless of whether you monetize your apps up front (paid apps) or downstream (using our In-App Purchasing Service).  

                  Second, we will be adapting the terms of the distribution agreement to provide more flexibility around timing for app submissions. You will now control which apps you will make available to Amazon customers, and when, as well as the countries in which your apps may be sold. As a reminder, it’s your responsibility to ensure your list prices do not exceed the lowest prices at which your apps and in-app products are sold in similar stores. To review the full agreement, including the two changes described above, please follow this link.

                  If you don’t already have a developer account, it’s easy to join and we’ve waived the annual fee for 2012  it’s free to register for a developer account. Sign up now, and start submitting your apps for international distribution later this summer!

                  We’re pleased to announce that you can now submit apps for distribution in the United Kingdom, Germany, France, Italy, and Spain using the Amazon Mobile App Distribution Portal.  We’ll begin distributing apps in these countries later this summer (and we have more countries planned in the near future).   

                   

                  June 17, 2012

                  Amazon Mobile App Distribution Program

                  Guest author Simon Newstead, CEO of Frenzoo, discusses designing games for monetization. In it he uses examples from Frenzoo's Style Me Girl, the first 3D fashion game on mobile. Simon can be reached at simon@frenzoo.com.


                  A Numbers Game


                  Our debut game Style Me Girl gained impressive downloads in its first two weeks, reaching the #1 position in the Amazon game charts. Whilst the downloads and rankings were nice, what made us really happy was the monetization, with Kindle Fire performing particularly well.


                  Style_Me_Girl_icon
                   


                  Mechanics


                  To look at what drives monetization it's always helpful to look at the core game mechanics:

                  Mechanics


                  In our case with Style Me Girl, the primary is a fashion puzzle mechanic where the player must dress a series of models for different Photoshoots, each with a unique fashion genre. The game uses a proprietary judging algorithm to determine scores, taking into account the items used, the fashion genre as well as the attractiveness of the photo taken. Passing the level unlocks the next level (model and fashion genre), progressing the story. Story evolves with new levels added dynamically from the cloud each week.

                  The secondary is a casual "catch the falling item" mini-game called Style Catch. Style Catch escalates in difficulty and provides and increasing payout of coins, used for shopping.

                  A freemium game, Style Me Girl has a hard currency Cash (purchased via IAP) and soft currency Coins, earned in Photoshoots and Style Catch.


                  5 Tips for Monetization


                  1. Incorporate a storyline

                  No matter the game type, if your game has levels, story serves up more motivation for players to progress through them. Players are emotional beings, and we are all compelled to be drawn into a good story. In our case, the game could have functioned just fine without a story line. However we saw from player feedback a deep engagement with the protagonist and goals in the story arcs. Given how little engineering resource is often needed on story, the ROI to include it is usually pretty compelling.

                  2. Replayability and collectibles

                  One thing that drives many paying users of Style Me Girl is successfully completing all levels with perfect 3 star results. Why? Of course completionism plays a part but the main one is being able to win rare "signature edition" items. These cannot be bought in the shop and a sign of success is sporting an outfit featuring 1 or more signature editions. It's always good to make room for replayability and collectibles can play well in that.
                   
                  3. Energy and speed up

                  It's a cliche but it's true - impatient players are paying players. Energy regeneration through paid items is a proven way to open up the purse strings. We saw that in Style Me Girl and cash purchase, even though Style Catch itself is just a game to let you earn the soft currency. Strange but it works.

                  4. Aesthetics and functionality

                  Whilst studies show that pure aesthetic items don't monetize as well as time saving and functional virtual goods, if you can combine them together that can work extra well. In our case the cash items bought in the shop are attractive fashions, which lets users both look good and play good. Combinations are always good. Think the success of Toms, based on looking good and feeling good about it. Or owning the latest Macbook Air, a style statement as well as solid productivity tool.

                  5. A/B testing

                  Like eating enough fiber, it may not be a glamorous part of game design but it certainly is necessary to get the most out of your game. We implement A/B testing in the major parts related to the in-game economy - coins earning rate, starting currency values, purchase conversion rate etc. We don't go to the point of A/B testing individual item prices yet though, but that's the direction. Running tests has helped us increase monetization while not affecting retention (not always the case), and it's something we're going to dive into even further.


                  Conclusion


                  These tips are certainly not rocket science and not the first time they have been used in games.That said, keeping these fundamentals in mind when designing your next game ensures you're getting biggest bang for your development buck. And that makes everyone happy.

                  June 11, 2012

                  Amazon Mobile App Distribution Program

                  Jeff Hines, Kindle Fire test team, and Chirag Mehta, a2z Developer Center Inc., an Amazon.com company, are our bloggers for this post.

                  This third post in our Top 10 App Optimizations for Kindle Fire series features actionable measures you can take when optimizing an app to correctly handle hibernation on Kindle Fire.

                  Your app must account for hibernation on Kindle Fire—whether the hibernation is user initiated or occurs after the screen times out. Similar to the Quick Settings optimization, hibernation optimization requires a proper handling of the onPause() and onResume() methods.

                  Not all apps react similarly when hibernated, as the expected behavior is dependent on the nature of the app. We have identified frequent hibernation issues and the solutions to correct them.

                  What is hibernation and what is the expected behavior?

                  When initiated, hibernation on Kindle Fire acts as a battery saver after a screen timeout or when a user taps the device’s power button. During hibernation, any active network connections are disabled by default. To return from hibernation, users are presented with the lock screen and must slide to resume.

                  Upon hibernation, the expected behavior for most apps is to enter a paused state, using the onPause() method, and then to restore app state upon return by using the onResume() method. Of course, apps that are static in nature and rely on user interaction to change state can simply run in the background during hibernation.  

                  In general, apps running in the background are expected to cease all background sound. However, some apps should continue to emit audio if this is their core functionality—such as music players or alarms.

                  My app requires an always on, active network connection. How do I ensure users stay connected during hibernation?

                  As mentioned earlier, network connections are disabled by default during hibernation as an additional measure to save battery life on Kindle Fire. Upon leaving hibernation, any previously connected network connection will be restored.

                  If your app requires an always-on, active network connection, then you can ensure that users remain connected during hibernation by using the following sample code:

                  try {
                              final PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
                              final WifiManager wm = (WifiManager) getSystemService(Context.WIFI_SERVICE);
                              final ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
                              final State wifi = connectivityManager.getNetworkInfo(ConnectivityManager.TYPE_WIFI).getState();

                              // Log the current WiFi state.
                              Log.i(LOG_TAG, getString(R.string.lock_service_status_current_state) + " " + wifi.toString());
                             
                              // Acquire the reference to the wake lock.
                              m_wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, getString(R.string.lock_service_wake_lock_name));
                             
                              // Ensure that the wake lock is reference counted.
                              m_wakeLock.setReferenceCounted(true);
                             
                              // Acquire a wake lock to keep the CPU running.
                              if (!m_wakeLock.isHeld()) {
                                  m_wakeLock.acquire();
                              }

                              // Acquire a WiFi lock to keep the WiFi radio awake.
                              m_wifiLock = wm.createWifiLock(WifiManager.WIFI_MODE_FULL, getString(R.string.lock_service_wifi_lock_name));

                              // Ensure that the WiFi lock is reference counted.
                              m_wifiLock.setReferenceCounted(true);

                              if (!m_wifiLock.isHeld()) {
                                  m_wifiLock.acquire();
                              }

                              // Perform the business logic.
                              performBusinessLogic();
                          } catch (final IOException e) {
                              Log.e(LOG_TAG, e.getMessage());
                              sendStatusMessage(e.getMessage());
                          } finally {
                              // Release the locks.
                              if (m_wakeLock != null && m_wakeLock.isHeld()) {
                                  m_wakeLock.release();
                              }

                              if (m_wifiLock != null && m_wifiLock.isHeld()) {
                                  m_wifiLock.release();
                              }

                              // Log the status.
                              final java.text.DateFormat dateFormat = DateFormat.getTimeFormat(this);
                              final Date date = new Date();
                              Log.i(LOG_TAG, getString(R.string.lock_service_status_release) + " " + dateFormat.format(date));
                          }
                      }


                  What can I do to ensure my app reacts correctly to device hibernation?

                  Apps that do not appropriately handle hibernation on Kindle Fire exhibit similar behavior to apps not optimized for Kindle Fire’s Quick Settings. When mishandling hibernation, apps may exhibit the following behavior:

                  • Apps may force close or crash
                  • App’s state or user save data may become lost or reset
                  • App’s videos may become interrupted or reset entirely
                  • Apps may enter an unrecoverable state upon return from hibernation
                  • Apps may continue to run in the background during hibernation—losing the user state

                  Much like our previous entries in the series, correctly implementing the onPause() and onResume() methods are key to resolving any negative behavior in association with hibernation. When hibernation is enacted, the onPause() method will be called during your app’s current activity. When returning to your app after the power button is tapped and the lock screen is slid, the onResume() method is called. To ensure that your app returns to its previous state before hibernation occurred, your app should save state in the onPause() method and reload the state in the onResume() method.

                  If your app plays audio clips using the MediaPlayer object, be sure to call pause() within the onPause() method, and start() in the onResume() method in your app.  This will ensure audio clips do not continue to play when the device hibernates.

                  For a technical perspective of the onPause() and onResume() methods, review our code segments included in part one of our Top 10 Optimizations for Kindle Fire series. To find more information about these and other methods, you may also find it helpful to visit: http://developer.android.com/reference/android/app/Activity.html

                  Check back for our next optimization post in which we will discuss ways to ensure your app installs successfully on Kindle Fire.

                  June 08, 2012

                  Amazon Mobile App Distribution Program

                  Over six weeks after launching the Amazon In-App Purchasing API for general availability, we connected with Jeff Spears, VP of Marketing & Sales, and Sean Thompson, VP of Production, Mobile Deluxe, to chat about their company’s experience with IAP on Amazon. Headquartered in Santa Monica, Calif., Mobile Deluxe is an innovator and publisher of social mobile apps and provides free-to-play casual games that emphasize premium quality and fun game play. Mobile Deluxe titles include Big Win Slots, Solitaire Deluxe, and Big Win Blackjack. 

                  What motivated Mobile Deluxe to integrate with Amazon’s In-App Purchasing solution?

                  "Mobile Deluxe is bullish on Amazon’s foray into the app space given its expertise in merchandising, coupled with the ease of 1-Click purchase. As an organization, we made the shift from pay-to-download to free-to-play in April 2010, and our free revenues eclipsed paid revenues by July of 2011. As an industry, freemium revenues are forecasted to reach $5B in 2016, driven by smart phone adoption and user comfort with the IAP model. As a publisher we like  the freemium model since it eliminates the barrier of entry into our game, and it allows players to enjoy our products regardless of their style of play. You can either “earn” currency through game play, or purchase currency at your discretion to accelerate your game as you see fit. While we support both styles of play, from a business perspective we aren’t capping potential earnings in the latter example."

                  What is your monetization strategy?

                  "Big Win Slots monetizes through IAP, whereas Solitaire Deluxe and Big Win Blackjack use a hybrid monetization model that uses IAP and Ads. For Solitaire Deluxe, the majority of our revenue is derived from advertising, allowing our customers to play for free, unlimited. This has led to outstanding engagement and retention, and our average play time for users is in excess of 30 minutes. For Big Win Slots and Big Win Blackjack, we felt the natural progression of currency in casino apps made great sense. IAP allows us better control over our revenue stream versus fluctuating advertising CPM’s in an ad-based product, and it allows for flexibility in merchandising opportunities such as in-game sales events."

                  How has your experience with Amazon’s IAP solution compared to that on other platforms?

                  "When making an apples-to-apples comparison in May to competitive app stores, Amazon is our #1 monetizing channel in terms of $/DAU. I’m sure you’re aware of the Flurry release stating “revenue from Amazon’s Appstore is now at 89% of iTunes App Store revenue” here. We find that our Amazon $ per Daily Active User exceeds the average on other top storefronts where our apps are distributed by 87%. This speaks to the frictionless 1-Click option and Amazon’s merchandising prowess which drove “Big Win Slots” to the #1 spot in the “Casino” category."

                  How did you find integrating the Amazon SDK and IAP API?

                   "Integration was exactly what we expected. We started from a baseline of already having integrated Google Checkout, so it was very easy to extend our existing functionality to include Amazon IAP. Amazon’s online resources were excellent. The “In-App Purchasing for Users of Google Billing” document was the perfect guide to help us get Amazon IAP integrated quickly. The API Reference was also helpful. Without question, this has been an ROI-positive experience for us. The total integration cost was about what we make in one day with Big Win Slots now."

                  Are there any tips you have to help other developers smoothly integrate the SDK?

                  "We recommend developers be forward looking when integrating any billing SDK. If at all possible, create an abstracted billing interface layer between your app(s) and the billing SDK. That will allow you to implement additional billing SDKs without having to make changes deep inside your project code. That means it is an easy tweak to add both Google and Amazon IAP solutions."

                  June 05, 2012

                  Amazon Mobile App Distribution Program

                  <p>The beta launch of Test Drive last week on select Android devices has many developers wondering, how does it work? Jeff Bar, Amazon Web Services Technical Evangelist, has taken the time to walk through the technology behind Test Drive on the AWS blog. Test Drive is hosted on Amazon Elastic Cloud Compute (EC2). The Amazon Appstore team can therefore easily add additional capacity whenever needed and where it makes the most sense with respect to the incoming traffic. We encourage you to check out <a href="http://aws.typepad.com/aws/2012/06/behind-the-scenes-of-the-amazon-test-drive.html">Jeff’s full post on the Amazon Web Services blog</a>.</p>

                  June 03, 2012

                  Amazon Mobile App Distribution Program

                  Aaron Rubenson, Director, Amazon Appstore, spoke at Open Mobile Summit in London about app monetization last week.  You can listen to the recording of the panel, App monetization: From Killer App to Killer Business, where panelists covered topics like: 

                  • Monetization: What's working today and why – from app sales, freemium, virtual goods, subscription, advertising and commerce?
                  • How big is the app market opportunity?
                  • How can app publishers build sustainable businesses? Which business models have longevity?
                  • New tools: Analytics, engagement, recommendation and discovery

                   

                  Learn more about the panelists by reading their bios on the Open Mobile Summit website.

                  Moderator:


                    Speakers:


                    Or listen to all available recordings from Open Mobile Summit here.

                    May 24, 2012

                    Amazon Mobile App Distribution Program

                    Jeff Hines, Kindle Fire test team, and Chirag Mehta, Michael Siwapinyoyos, and Steve Johnson, a2z Developer Center Inc., an Amazon.com company, are our bloggers for this post.

                    The second post in our optimization series discusses optimizing your app’s layout for Kindle Fire and accounting for the soft key bar.

                    In addition to the Settings bar that we mentioned in our previous post, Kindle Fire also has a soft key bar that is present at all times. Rather than physical buttons, Kindle Fire uses soft keys to display the standard Android buttons (i.e., Home, Back, Menu, and Search).

                    Optimizing your app for the soft-key bar provides a more positive customer experience. In this post, we present optimizations and sample code to address frequently asked questions and common issues you may encounter when developing your app for Kindle Fire.

                    How do I optimize my app’s layout for Kindle Fire?

                    When developing exclusively for Kindle Fire, please ensure that your app is optimized for the following specifications:

                    • A “Large” 7” screen size
                    • A Medium Density (mdpi) screen with an abstracted LCD density of 160
                    • 600 pixel width by 1024 pixel height in portrait mode

                    Note that the Kindle Fire will reserve 20 pixels to display the soft key bar, as stated previously; therefore, the true pixel height, including the soft key bar, is 1004 pixels in portrait mode.

                    Apps optimized for Kindle Fire should take advantage of the large screen size. Your app should scale its interactive elements accordingly. This provides the best possible customer experience.

                    Use these screen specifications even if your app is not optimized exclusively for Kindle Fire. A best practice is to create resources specifically for large screen devices with medium density displays (mdpi).  

                    To scale a background image, specify taking as much space as available within the layout element, using the following code snippet:

                    <ImageView
                    android:layout_width="fill_parent"
                    android:layout_height="fill_parent"
                    android:scaleType="fitXY"
                    android:src="@drawable/yourbackground"
                    />

                    Use the Bitmap.createBitmap() method with caution. While it can scale resources to fit the screen, it can also take additional computing cycles and require a lot of additional memory.

                    Please note that Android does have a built-in resource selection algorithm that will attempt to match declared resources with the characteristics of the device that your app is being displayed on. More detail regarding multiple Android screen support can be found here: http://developer.android.com/guide/practices/screens_support.html.

                    How should my app handle rotation on the Kindle Fire?

                    While not specifically about your app’s layout, errors with orientation changes are frequently encountered. Rotating a device from landscape to portrait (or vice versa) without the appropriate optimizations can result in the following issues:

                    • Your app force closing
                    • Crashing or returning users back to the carousel on Kindle Fire
                    • App state or user save becoming lost or reset

                    A screen orientation change will always fire the onCreate() event, destroying and recreating the activity. If you do not take this into account, you could run the risk of a negative user experience.

                    To properly handle a screen rotation and avoid the issues outlined above, you can follow these best practices:

                    • Name the views in your activity using the android:id attribute. When there is an orientation change in your activity, Android will persist the state of a named view and restore it once the activity is recreated. When an activity is destroyed, the state is saved only for named views.
                    • The onSaveInstanceState() method is fired when an activity is destroyed. You can override this method to save your app state. Once the orientation change is complete, and your activity’s onCreate() method is called, onRestoreInstanceState() is automatically called. This method can be overridden to restore you app state. This mechanism relies on simple data structures to be used; i.e., state information needs to be structured in a Bundle object.
                    • If your app needs to save a complex data structure, then you can use the onRetainNonConfigurationInstance() event. This event returns an arbitrary Object event, so you can persist as complex a data structure as is necessary for your app. Call getLastNonConfigurationInstance() inside your onCreate() method to retrieve your activity state, but remember to cast the class properly.

                    Although not the best solution for all apps, preventing orientation change will allow you to avoid these issues entirely. To lock your app to a specific orientation, include the following entry in your manifest file.

                    android:screenOrientation="portrait|landscape"

                    How can I effectively use the soft key bar?

                    The soft key bar enables simple, quick, and efficient navigation from within your app and all other aspects of the device.

                    The soft key bar has two positions: maximized and minimized. When minimized, the soft key bar takes up 20 pixels and displaces your content. When maximized it takes up 60 pixels; 20 pixels displace your content and 40 pixels sit on top of your content.

                    How should my app interact with Kindle Fire’s soft key bar?

                    To be compatible with Kindle Fire, apps must account for and interact with the soft key bar. The soft key bar contains four different soft keys:

                    • Home
                    • Back
                    • Menu
                    • Search

                    Using the Home Soft Key

                    Kindle Fire uses these keys to display the standard Android device buttons. Apps must appropriately use the Home soft key to allow quick navigation to and from the Kindle Fire carousel.

                    By default the Home soft key returns users to the Kindle Fire carousel. When the home key is pressed, the current activity’s onPause() method will be called before the user is presented with the carousel. When your app is re-launched, the onResume() method will be called. In order to ensure that the app returns to its previous state, your app should save state in the onPause() method and reload the state in the onResume() method.

                    For more information about the onPause() and onResume() methods, please see our previous blog post in the Top 10 Optimizations for Kindle Fire series.

                    Using the Back Soft Key

                    The Back soft key's default action is to call finish() on the current activity and then resume the previous activity on the stack (as managed by the OS).

                    If your app has launched several activities and you want the Back soft key to return the user to the previous activity, then you don't need to do anything—this is the default behavior. If the user is already at the main activity of your app, the Back soft key will call finish() on the activity and exit your app.

                    A typical solution to prevent premature exiting of the app is to override the Back soft key functionality on your app's main activity to trigger a confirmation dialog. Override the function of the Back soft key in an Activity by including the following code in the Activity class:

                    @Override

                    public void onBackPressed() {

                       // do something when the back button is pressed

                       return;

                    }

                    Stay tuned for our next series post, as we tackle device hibernation!

                    Want the latest?

                    appstore topics

                    Recent Posts

                    Archive