Windows Phone Store and problems with payments

I have been a Windows Phone developer for over a year now and my paid apps made me some money. The small amount of money made is not interesting, more interesting is that getting the money from Microsoft has been a real pain. Maybe because I live outside the US, maybe it is a geographically independent problem. If you are a developer and live outside the US, I really want to hear your experience.

No exact info about payment rules?

First, there is no exact information about how often a developer gets paid. The getting paid section in the Windows Phone Dev Center only informs you about tax and bank info, that you need to provide to get paid. I remember that I once heard that developers get paid when their earnings get pass $200, but I was not able to get any official info about this. The first payment I got from Windows Phone Store was $52.50 and I know a developer with $900 earned and no money sent to him, so I guess the $200 limit is not true.

The $200 limit should be true for Windows Store, but Windows Phone Store is a different store with different rules.

No info about pending payments

Suppose the $200 limit is true. (Windows Store states: “To get paid from the Windows Store, you must have at least $200 in app sales pending payment”) It would be really useful to know how much money your apps have made in total and from the last payout, or in other words, the pending payments. Microsoft does not provide such info. Even the support is not able (or willing) to tell you this info.

The only info you get is the number of paid downloads of your apps. You need to multiple this per-app numbers by the price of your apps and subtract the 30% cut that Microsoft keeps for themselves. If you changed the price of your apps at some point, or have different pricing for different countries, the math becomes really overwhelming.

Distimo to the rescue?

Distimo is a great app analytics service that supports Windows Phone Store. You give it your credentials and it downloads and displays all the data from Windows Phone Store for you. And guess what, it can display the amount of money you made. I do not know how they do it. Maybe they use the exports that Windows Phone Store offers, but when I try to download them, they are always empty. Maybe they just do the math I mentioned… Anyway, it really sucks that you have to use a 3rd party tool to get the info that Microsoft has and should provide to a developer.

Really getting paid

Only my first payment of the strange $52.50 was automatic. When my next earnings according to my calculations crossed the limit of $200 (or $252.50 taking the $52.50 payment into account), I was expecting to get paid. The payment did not come for months. I asked my local Microsoft branch for more info, but I did not get any useful answers. So I tried another tactic.

I made a bit of a fuss about this issue on Twitter, where many developers from my country joined with their complaints about being in the same situation, mentioning our local Microsoft evangelist in their tweets. In two weeks, we all got our payments from Microsoft (coincidence?).

The payment did not come in $ but in CZK. Its value was approximately $240. The Windows Phone Store now shows me I received two payments in two different currencies and in some statistics adds the two payments up as they were both in CZK ($52.50 + 4,806.88 CZK = 4859.38 CZK in their world).

Answers from Microsoft

I contacted my local Microsoft branch and sent the following questionsto two evangelists, hoping to get answers for me and other developers:

      When does a developer get paid from Windows Phone Store? Is there any limit that needs to be crossed (like $200 in Windows Store)?
      Are these getting paid rules officialy stated anywhere? The MSDN page does not contain any useful info.
      Is there a way to know how much I have made in total / since last payout? I mean other way that doing the math from app downloads and prices. (A fellow developer told me that even your support does not know / want to give the info.)
      Are payments automatic? (If there are exact rules)
      To get my last payment I needed to contact out local MS branch, do I need to do it every time I feel I made $200 since my last payment (which is now)?

I got the following answers (after involving other developers and putting some pressure on them):

      7b of the APA: Application Proceeds will be calculated on a monthly basis by deducting the Store Fee from Net Receipts for the applicable month. If total Application Proceeds payable to you for a month exceed USD$200 (or its equivalent in local currency), then Microsoft will remit payment to you in
      accordance with this Section 7.
      Can you clarify what you mean by rules? As long as a dev has over $200, and has valid bank & tax, then they will be attempted in payout.
      Currently we do not have a report that provides the total of the settled transactions for a developer.
      Payments are automatically attempted once the developer reaches the threshold
      No, payments are automatically attempted once the developer reaches the threshold

Conclusion

Microsoft confirmed the $200 limit for getting paid altough my experience does not corespond to this statement. I still wonder why this information is not available somewhere on AppHub or MSDN. They sent me a file called Windows-Phone-Store-Application-Provider-Agreement.pdf but I was not able to find any reference to it anywhere, just the whole file at a strange url. Having this crucial info hidden in a PDF file where no developer can ever find it does not seem ok to me. The whole payments process does not look very transparent.

They also confirmed that there is no way to know how much money you made, so you have to rely on Distimo. They assured me that my next payment will be automatic, so I guess I just have to wait and see …

Posted on May 20, 2013 by Igor Kulman in Windows Phone

7  

Useful tools for Windows Store developers

I recently discovered two really neet tools that helped me with Windows Store app development.

Windows Store Icon Maker

When creating a Windows Store or Windows 8 apps, there are many icon sizes you have to provide. If you do nont wat to do all the resizing by yourself, you can use the Windows Store Icon Maker. It is a fork of the Windows Phone Icons Maker with added support for Windows Store apps. It takes a 300x300px icon as input and outputs all the square icons you need.

HAMMER.Pants

To brand Windows Store apps written in XAML, you need to override all the control styles. This sucks if you just want to change the colours to match your theme. HAMMER.Pants solves this, by auto-modifying all the coloured brushes so you don’t have to pick through them. Currently, you provide a “base” colour, and HAMMER.Pants modifies that based on the luminance variation found in the original styles. That is, if you pick red, all the purples will be replaced with reds, but they’ll change in brightness slightly just like the default purples do.

Posted on April 18, 2013 by Igor Kulman in Windows Phone, WinRT

1  

Do you need to create a special Windows Phone 8 build of your Windows Phone app?

If you create a Windows Phone app and you want it to be able to run on both Windows Phone 7 and Windows Phone 8, you target Windows Phone 7 and the app runs on Windows Phone 8 automatically. But is it really enough to create a Windows Phone 7 buíld? Not if you want to create a really well designed app.

The problem with Windows Phone 8 from a designers point of view is that it introduces two new display resolutions. Windows Phone 7 supports just one resolution, WVGA of 800x480px. Windows Phone 8 adds WXGA (1280×768) and 720p (1280×720). If you run your Windows Phone 7 app on a WXGA device, the app is proportionally scaled by a factor of 1.6 to fill out the whole screen. As long as you provide all your images scaled by the same factor, the app looks ok.

The problem is 720p, because it is a different aspect ratio (16:9 vs 15:9). Your Windows Phone 7 app running on a 720p app is first scaled by a factor of 1.5 to 1200×720 and the rest of the display (80px) is padded on top or bottom, depending on the VerticalAlignment. By default, the padding is added to the top of your app making your header 80px higher:

wp7header

This makes all the Windows Phone 7 apps look bad on a 720p devices like the HTC 8X I currently use. If you create a Windows Phone 8 project with exactly the same XAML, the app will look ok on a 720p device, no padding added to top or bottom. Another advantage of a special Windows Phone 8 build is that the app will start much faster.

To sum it up, if you want your app to look great on all devices, always create a separate Windows Phone 8 build. It is usually as simple as creating a new Windows Phone 8 project and adding all the existing files as links. You can find more info about this technique on Nokia Dev Wiki.

Posted on April 15, 2013 by Igor Kulman in Windows Phone

1  

Displaying PDF files in Windows Store apps

Displaying PDF files in a mobile apps is a valid use case and there are many iOS and Android app that do it. WinRT has no APIs for displaying PDF files. The only thing you can do with a PDF in WinRT is to display it in the default PDF viewer app using the Windows.System.Launcher.LaunchFileAsync method. This is typicaly not what you want to do. This method takes the user out of your app and more importantly the PDF can be copied, shared, etc.

There are a few 3rd party components for displaying PDF files in Windows Store apps, each has some problems and restrictions.

ComponentOne PDFViewer

ComponentOne has a PDFViewer component as part of their Studio for WinRT XAML package. This package costs $895. There are many limitations when using this component that you need to be aware of. If you want to have more control over the rendered PDF files, you can get all the pages as FrameworkElements and do not need to use the PDFViewer as one monolitic component. It does not support all the fonts and complex documents are rendered really messed up, it was not usable for me at all.

Foxit Embedded PDF SDK

Foxit has a Embedded PDF SDK for Windows RT and Embedded PDF SDK for Windows Store Apps (what is the difference?). If you want to try it, you have to fill in a registration form. There is no information about pricing and you need to fill in another form to ask for a quotation. You can get the pages of the PDF files as images if you want more control, but the component only works with StorageFiles. It cannot open a custom stream (e.g: file in isolated storage with custom encryption).

TallComponents PDFRasterizer

TallComponents has a PDFRasterizer component that is currently in beta. You need to join the beta program to get access. The final version should be out in 6-8 weeks. PDFRasterizer costs 1490€ for a single app. It is just a rasterizer, you can get the pages of the PDF files as images and that is all. It works well with differents fonts and complex documents.

PDFTron Mobile PDF SDK

PDFTron has a Mobile PDF SDK that works with Windows Store apps. To get a trial version you have to fill in a form where you have to describe your app. The pricing is not clear, it dependes on many factors and you need to write them an email to get a price. You can get pages from the PDF file but not in a usable format like an image.

So which PDF solution should you use? That dependes on your needs. I am afraid you will have to check each of them out by yourself and assess it according to your needs.

Posted on March 27, 2013 by Igor Kulman in WinRT

Tags: , ,

14  

Windows Store limits the number of in-app purchases for an app

Windows 8 development has many problems and pitfals because of WinRT. Windows Store, the only desitibution channel for Windows 8 apps, has som problems too. One of them is really serious for everyone who wants to create a newspaper or newsreader app with in-app purchases.

We developed a Windows 8 app for a local newspaper. The content consists of issues, there is one issue published each work day. The users can buy the issues using in-app purchases. The problem is that there is a limit of 100 in-app purchases that can be defined for a single app in Windows Store. I really do not know what would Microsoft impose such a limit.

As far as I know there is no way around the limit. We need to either delete in-app purchases for old issues so user will no longer be able to buy them (which is stupid) or create new app with a different name and in-app purchases for another time period (which is even more stupid).

Sure you can implement content purchasing using other ways, but they all have one big problem. There is no way your app can get the identity of the user. If you implement your own purchasing mechanism, you cannot pair the purchases with the user, only with the device. So the user would have to buy the same content on each device, if he reinstall his system, etc. That is usually not what you want.

Posted on March 21, 2013 by Igor Kulman in WinRT

Tags:

3  

My Windows Phone and Windows 8 mini-libraries

I am a big fan of open-source software. I decided to make my mini-libraries, that I use for Windows Phone and Windows 8 development, available to everyone who would be interested. Both are basically a collection of useful utilities and components that I wrote myself or found on various forums and slightly modified. Source code is available on BitBucket and packages on Nuget.

Windows Phone

Code: http://code.kulman.sk/kulman.wp7
Nuget: https://nuget.org/packages/Kulman.WP7/

Windows 8

Code: http://code.kulman.sk/kulman.winrt
Nuget: https://nuget.org/packages/Kulman.WinRT

My Windows 8 mini-library is best used with the WinRTXAMLToolkit that I contributed to once ot twice.

Posted on March 18, 2013 by Igor Kulman in Windows Phone, WinRT

Tags: , ,

0  

The problem with Windows 8 development is the WinRT’s lack of capabilities

Let’s face it, there are no really great apps for Windows 8 and the number of trashy apps is also very low compared to the Android and iOS ecosystems. Microsoft looks really desperate to bring more apps and developers to the ecosystem. Instead of improving the API and its capabilities, Microsoft just generates desperately looking campaigns to improve the apps count. I sometimes wonder if they ever realize that the number of apps is not important when people cannot find the apps they are used to use on Android or iOS in the Windows Store.

So why are there so few Windows 8 apps? I will tell you my (and only my) opinion and experience. I developed a few Windows 8 apps, some of them fairly complex. I tried to develop a few really great apps but many of those projects never got done. The reason is the API (WinRT).

Let’s start with something (that should be) trivial. Imagine you want to display HTML files with images, CSS, JS in a WebView. It is a common scenario for displaying downloaded manuals, interactive texts, etc. It can be done on Android, iOS and even on Windows Phone by copying the data to isolated storage and pointing the WebView there.

This scenario is impossible in WinRT. You can reference files in Isolated Storage (Local / Roaming folders) using the ms-appdata protocol, but the WebView does not work with it. You can use the NavigateToString method to display one HTML file, but all the images, CSS, JS references must be internet URLs, you cannot reference other local files. The only way around this issue is to inline all the CSS, JS and images (as base64) to the HTML file. Really messy, painful and slow and not really an option if you have JS reading XML files and inserting external images.

There is another workaround pointed out by Javier Sosa in the comments. Instead of saving your files to Local / Roaming folders, save them to the installation folder of your app (Windows.ApplicationModel.Package.Current.InstalledLocation) and use the ms-appx-web protocol. The WebView can for some reason work with ms-appx-web but not with ms-appdata. Saving your data to the installation folder instead of data folders is quite messy in my opinion. Another problem is, that you cannot create folders in Windows.ApplicationModel.Package.Current.InstalledLocation. This means you have to preprocess your HTML,CSS,JS files and make the file structure flat. Turns out this works only in debug, so it is not a viable workaround.

Let us continue with something as basic and common as Zip files. Windows 8 offers absolutely no protection of your locally saved files so a client may want to at least use password protected Zip files. The ZipArchive class in WinRT does not support password protected Zip files. No 3rd party Zip library can be compiled in WinRT because of a missing Security namespace. You are out of luck, there is no workaround and it may be a deal-breaker for a security-conscious client.

Update: ComponentOne has (really bad SEO and) a Zip component for WinRT that supposedly works with password protected files, except that it does not and nobody really cares.

Do not even get me started on using a custom Stream implementation to encrypt your locally stored files …

Let us assume that you want to create an interactive textbook app like there are a few on iOS. The apps should contain multimedia content like images, video, sounds, Word and Excel documents. You would assume that displaying (or better said previewing) Microsoft Word and Microsoft Excel files on a Microsoft platform would be easy. You should have learned to limit your expectations and always assume the worst by now when dealing with WinRT. You can display Word documents with a component for $199 and Excel sheets with one for $1195. Previewing Microsoft Office documents on iOS is easy and built-in.

Do you need your app to display PDF files? There are a few solutions, mainly in beta and each has some flaws. I will write a separate article about rendering PDF files in WinRT but, again, be prepared to spend at least $900 for something that can be done for free on other platforms. Sure, you can send the PDF file to the default PDF viewer but that is usually not what you want. It takes the user out of your app and more importantly you cannot protected the PDF content from copying, sharing, etc.

Do not forget about the strange behavior of the Windows Store certification process and the bugs.

I am really fed up with telling customers who want an (complex iOS clone) app the magic words “it is not possible in Windows 8″.

Posted on March 14, 2013 by Igor Kulman in WinRT

Tags: ,

43  

Few thoughts about the Windows (Phone) Store certification process

Passing the certification in Windows Phone Store and Windows Store can be a very painful process, but after a few tries you get enough experience to pass your apps on the first try. You may sometimes get a tester who is really dumb and fails your app for a made up reason but usually it is just enough to submit it again so another testers gets to test it. Lately I have been seeing a strange shift in the testing quality done in the certification process.

Windows Phone Store

The certification process used to discover bugs I overlooked, so it was quite useful sometimes. But it is not anymore. Let me give you an example. I wanted to change one of my Windows Phone apps from free to paid with a 3 day trial. I have this functionality implemented in another of my apps so I simply copied the trial page, set is as the start page. I tested it in trial mode, it showed, in purchased mode, the app showed the real start page. I was under the impression that everything worked just fine.

The app update passed the certification process without problems although it had one serious flaw discovered by new users. When a user started the app in trial mode, the trial page was shown. The trial page consisted of two buttons. One button to buy the app and another button to continue the trial. The button to continue the trial made the app crash. It is definitely my fault for not testing it properly but what did the Microsoft tester do for 5 days that they did not discover this bug? They may have tested in in purchased mode only, but that does not make any sense. I am inclined to believe the did not test it at all, just held it for 5 days.

Windows Store

The certification requirements for Windows Store apps are more strict that the ones in the Windows Phone Store. The testers can fail you for reasons like “the app does not do anything useful”. And they sometimes do when they do not get what your app is supposed to do, usually when your app is not in English. The rule that the app should do something useful is a great rule in my opinion. But take a look at the Windows Store, there are tons of trashy apps that are not useful.

Another problematic rule is the rule that your app must be (or seem) finished, especially when you combine this rule with a dumb tester. I had problems with this rule with my tv guide app. It got rejected many times because the tester complained he could not watch tv using the app. I had to write a note explaining what a tv guide means and keep resubmitting it until I found an intelligent tester.

On the other hand when I updated one Windows Store app and broke half the functionality in the process (I am not a very thorough tester) nobody complained and the app passed the certification process in a few hours.

My experience is that the certification process in both store works very strange. They fail you for made up reasons and pass your apps when they are broke. Maybe there is something broken with the process.

Posted on February 28, 2013 by Igor Kulman in Windows Phone

Tags: ,

5  

F# on Azure: using Table Storage for logging

Windows Azure finally has a good F# support. Creating F# Worker Roles is supported right from the wizzard in Visual Studio and you can create a F# Web Role using the F# C# MVC template. I decided to try it out and the first thing I needed to implement was logging. I decided for logging to Azure Table Storage.

I assume you have a basic idea of how Azure Table Storage works. If not, there is a good guide on the Windows Azure website.

The first thing you need to do is to define your log entry class. You need to create a class, Azure Table Storage does not work with F# records. In my case I want to store a timestamp, message and severity.

[<DataServiceKey("PartitionKey", "RowKey")>]
type LogEntity() =
    let mutable partitionKey = ""
    let mutable rowKey = ""
    let mutable message = ""
    let mutable timestamp = DateTime.Now
    let mutable severity = ""
    member x.PartitionKey with get() = partitionKey and set v = partitionKey <- v
    member x.RowKey with get() = rowKey and set v = rowKey <- v
    member x.Message with get() = message and set v = message <- v
    member x.Timestamp with get() = timestamp and set v = timestamp <- v
    member x.Severity with get() = severity and set v = severity <- v

Alternatively you can make your class inherit from TableEntity that already contains the PartitionKey and RowKey properties. The Severity property is in my case just a simple discriminated union

type Severity =
    | Debug
    | Information
    | Error
        with
            member this.toString() =
                match this with
                | Debug -> "Debug"
                | Information -> "Information"
                | Error -> "Error"

You can access the Azure API in C# way but you do not need to, there is a great library called Fog by Dan Mohl that makes using Azure API from F# more comfortable.

First you create a Azure Table Storage client using a connection string defined in the Windows Azure Cloud Service Configuration file for a role

let client = BuildTableClientWithConnStr "TableStorageConnectionString"

Saving a log entry is then very simple thanks to Fog

let log (severity:Severity) message =
    let entry = LogEntity(PartitionKey = DateTime.Now.ToString("yyyy-MM-dd"), RowKey = Guid.NewGuid().ToString(), Timestamp = DateTime.Now, Message = message, Severity = string severity)
    CreateEntityWithClient client "LogEntity" entry

Saving data to Azure Table Storage may be a slow operation if you do it a lot, so you may want to log asynchronously

let log (severity:Severity) message =
        async {
            let entry = LogEntity(PartitionKey = DateTime.Now.ToString("yyyy-MM-dd"), RowKey = Guid.NewGuid().ToString(), Timestamp = DateTime.Now, Message = message, Severity = severity.ToString())
            CreateEntityWithClient client  "LogEntity" entry
        } |> Async.Start

As you may have noticed, I use the date as the partiotion key. The thing with Azure Table Storage is, that you can get the data by partition key, row key, or all the data. The log date seems like a reasonable partition key that allows you to get log by days

let getLogs (date:DateTime) = seq {
         for e in client.GetDataServiceContext().CreateQuery<LogEntity>("LogEntity") do
            if e.PartitionKey = date.ToString("yyyy-MM-dd") then
                yield e
    }

Update: there is a more way to create the LogEntity using the CLIMuttableAttribte

[<CLIMutable>]
[<DataServiceKey("PartitionKey", "RowKey")>]
type LogEntity =
    {
        Message: string
        Timestamp: DateTime
        Severity: string
        PartitionKey: string
        RowKey: string
    }

Posted on February 26, 2013 by Igor Kulman in Functional programming, Windows Azure

Tags: ,

11  

Reading Excel sheets using F# without COM

I needed to create an utility that would read Excel 2010 files (.xlsx) and generate XML files from them according to some specific rules. The catch was that the utility needed to run on MacOS instead of Windows.

Reading and writing Excel files from .NET is very easy using the Microsoft.Office.Interop assemblies but they use Excel through COM and that makes them unusable outside of Windows. I found some 3rd party libraries for working with Excel and analzyed them with The Mono Migration Analzyer (MoMA). MoMA is a handy tool that analyzes .NET assemblies and tells you if they will run on Mono. Many of the Excel libraries I found were unusable for my use-case because they were using PInvoke calls. Only the ExcelPackage library runs on Mono.

I wanted to use the ExcelPackage from F# not C# so I wrote a very simple F# wrapper, that you can freely use. For now it contains just a few methods

Excel.getWorksheets
Excel.getWorksheetByIndex
Excel.getWorksheetByName
Excel.getMaxRowNumber
Excel.getMaxColNumber
Excel.getContent
Excel.getColumn
Excel.getRow

but I will be adding a few more soon. The usage is really simple. For example, if you want to read the whole sheet number 1 from a file called text.xlsx, use

let data =
        "test.xlsx"
        |> Excel.getWorksheet 1
        |> Excel.getContent
data
    |> Seq.iter (fun x-> printfn "%s" x)

EDIT: Now available as a Nuget package:

PM> Install-Package ExcelPackageF

Posted on February 6, 2013 by Igor Kulman in Functional programming

Tags: , ,

1