The following forum(s) have migrated to Microsoft Q&A (Preview): Developing Universal Windows apps!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

[UWP][W10M] First access to CurrentApp.LicenseInformation very slow on Windows 10 Mobile RRS feed

  • Question

  • Users made me aware that my app starts very slow on Windows 10 Mobile, depending on network availability. I have narrowed this down to the license which is checked during startup, to control which parts of the app get initialized. On both the PC and on WP81, license information is always super fast to access, no matter if the device is in flight mode, on wifi or cellular connection, because the OS caches the license information. But on Windows 10 Mobile, the first access to LicenseInformation is only fast if flight mode is on. It looks like only in this case, cached license information is used. But if WiFi is on, it takes about 1-2 seconds to access the license, looks like the device retrieves the license from the server instead of using the cached info. If the phone is on cellular data with good connection, it takes about 3-7 seconds. And if the connection is very bad, it can even take a lot longer, or sometimes my app will even be killed by the OS because it took too long to start. Any further access to LicenseInformation is fast, but first time it is accessed, the OS always seems to retrieve a new license from the server although the license is available in the OS license cache.

    Why does Windows 10 Mobile not use cached license information like WP81 does and like the PC version does? The information is definitely there, because in flight mode the IAPs are available. We are advised to not store or cache license information and to rely on the OS instead and always use CurrentApp.LicenseInformation (also for enhanced security, so people cannot fake license by patching local data). But we can only do this if the access to LicenseInformation is fast. It if takes 20 seconds to access it, I cannot explain this to my users.

    In older insider preview builds of W10M, there was even a problem where license caching did not work at all. In flight mode, an exception was thrown and IAPs were not available. This was solved, but now it looks like caching is only used in flight mode. I would expect cached license to be always used to allow fast access, just like on PC and on WP81. On WP81 my app always starts fast, no matter if in flight mode, in wifi or on cellular data.

    Wednesday, May 4, 2016 9:20 PM

All replies

  • Hi Lukas F,

    Could you please tell us what is your Windows 10 Mobile version? This can eliminate the problem caused by different versions.

    May be it's a problem caused by the software on the mobile device. So could you tried to test it using other Windows 10 Mobile devices? 
    If you do not have any other Windows 10 Mobile device, I would suggest you reset your current mobile device to test.

    Best Regards
    Leon Guang

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, May 5, 2016 6:55 AM
  • Hi Leon, this happens on both my phones, they are on release preview branch (10.0.10580.242), and it also happens on user's phones who are on the official version. I have done a reset and it does not change anything. My users say that this has happened since a long time already. I did not really notice since I usually test at home with wifi, and my daily driver is still a WP81 device.

    On older W10M versions, it was even worse as I said. License caching did not work at all and the app would crash in flight mode (until I added try/catch around LicenseInfo access). Now it does work but the cached license is only used when the phone is in flight mode. LicenseInfo is not an async method, it is expected to return a result immediately from the OS license cache.

    • Edited by Lukas F Thursday, May 5, 2016 8:54 AM
    Thursday, May 5, 2016 8:54 AM
  • Hi Lukas F,

    For this issue, we are trying to invoke someone experienced to help look into it, it may take some time and as soon as we get any result, we will tell you.

    Best Regards,
    Leon Guang

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, May 9, 2016 2:53 AM
  • I'm having the exactly same issue.

    At first I thought it is just another issue of .Net Native compiler (because my startup performance in Debug mode was much better than in Release mode). But after reading this thread, I could narrow it down to the same thing.

    In Debug mode, I use CurrentAppSimulator, while in Release mode I use CurrentApp:

    #if DEBUG
        var result = await CurrentAppSimulator.RequestProductPurchaseAsync(productId);
        var result = await CurrentApp.RequestProductPurchaseAsync(productId);

    Using CurrentAppSimulator (or CurrentApp in Flight-mode), my app launches in about 2-3 seconds. But using CurrentApp, it takes 5-20 seconds (depending on the internet connection).

    This is pretty bad. The users of my apps are complaining about bad performance since a while (on Lumia 535, ...). Personally, I test my apps on a Lumia 930 (10586.420).

    I guess there is no reason to check whether or not the IAPs have been purchased each time the app is launched. I always thought that IAPs work more or less like a local certificat file that is installed e.g. when an app is installed or when the user purchases an IAP.

    To narrow it down even more, I did some time measurements:

    var licence = CurrentApp.LicenseInformation; // ~0.72 seconds
    var product = licence.ProductLicenses[productId]; // ~5 seconds
    var isActive = product.IsActive; // ~0.00001 seconds
    Further calls to these function take about 0,01 seconds in total. 

    Thursday, June 23, 2016 3:36 PM