Deleting & re-loading to get around Trial Mode

Is there anything preventing a user from deleting and re-loading an app to circumvent use duration limitations imposed by a trial version of an app ?

I don't intend to use the "Trial Mode" that shows up in the documentation, but the problem is the same no matter how you implement it.

If you want the user to be able to try out the app for a day, or a week, or a month before buying.... is there a way to accomplish that ?

My understanding is that all stored data relating to the app is removed from the device when the app is removed, so the app doesn't seem to have any way to detect re-loads, or to find data that might have been stored indicating that the trial period had expired.

Thoughts ?

Thanks

  • You want to look at the uniqueIdentifier available in the System.DeviceSettings.  It is string that is consistent for an app across installs and is unique to a device/app comb.  Keep in mind that this only available since 2.4.1, so it does not work on older CIQ1 devices although those are becoming fewer as time goes on.

    developer.garmin.com/.../DeviceSettings.html

    One way to accomplish what you want is to validate your trial with a registration server.  Then the app can send the UID to the server to see if the trial is still valid.  If no entry record the UID and set the trial window.  If found return the expiration date of your trial window.  If the expiration date is in the past, display trial over message, otherwise, use as normal.

    If you are going through the process of setting up a trial, you are also probably looking at a registration system so an online method is the most reliable way I can think of that would survive status across reinstalls.

  • Thanks for this.

    It's a good thought but for the moment my app doesn't communicate over the internet so I'm looking into other approaches.

    Also not planning on using Garmin's Trial approach given what I've read on the forums.

    Thanks

  • If you come up with a way that does not involve communicating with a server, I would be interested in how you do it.  Right now I cannot think of a way that does not involve an off the watch method that will work across reinstalls.

  • I agree. I don't think there's a way to accomplish what I'm asking given the limitations Garmin imposes, so I'm looking into alternate ways to restrict a Trial.

    Thanks again for your input.

  • the app trials from Garmin does not include communication from on the watch, you will have to provide an unlock url but the app store will do this initiation of communication, not the watch.

    docs are here: https://developer.garmin.com/connect-iq/core-topics/trial-apps/

    an example implementation can be seen here:  apps.garmin.com/en-US/apps/625e93a4-3a02-4109-84e3-e0659a49708c

  • Hello Peter.

    I've read and re-read the documentation about trial apps, as well as looking through discussions on the forums about how it works and whether developers are having any success using it. The discussions indicating that it is not intended for independent developers to use but is intended for partner organizations to use and that there's some approval process that won't include independent developers was off putting. That said, from what I read, the Trial mechanism will not prevent a user from deleting and re-downloading a trial version, so if the trial is built to provide full functionality for some number of hours or days or weeks, the user can just start again when the trial period expires.

    Is that true, or have I missed something ?

  • as far as I'm aware this is open for anyone, the document mentions that the developer needs to go through an approval process (I'm not sure what it involves, but it doesn't mention this is for partners only). 

    The docs mentions something about time-based trials, I would assume this spans over app uninstall/reinstall.

    If I were you I would ask that question when you go through the approval process as I understand if the time-based trial would not work accross app uninstall/install that this would be a deal breaker from your side. 

  • Back when this first came out a few years back, I recall it really needs a full blown payment system.  Not just a paypal link.  When a user pays, the payment system needs to tell the app store.

    This part makes it really hard for a small developer to implement.

  • it doesn't look so complicated jim: you need to provide an unlockurl (which I assume gets passed some kind of uniqueidentifier), after succesfull payment processing you call the callbackurl.

    this can be a pretty small php script.

  • Any chance of getting that question answered before doing the work and applying for approval ?

    It seems to me that if it does not work across uninstall / reinstalls it should be viewed as a deal breaker for anyone who is providing full functionality for a limited time.