I'm about to implement some unlock-functionality In-App-Purchase in an app. The client would like the functionality to be available the first two weeks after installing the app, and then go away until the user pays up.
I need the app to determine whether it has been previously installed, deleted, and installed again. If I can't do that users can just reinstall the app and get two more weeks for free.
Any ideas?
It seems all data is deleted when the app itself is deleted, which kind of limits my options. There is a server backend to the app. Is my best option to log something there or is there another way?
You can make use of the keychain in iOS. It will not be removed even if you uninstall the app. But you have to make sure you use the same provisioning profile across different versions of your application.
And, have a look at this utility
Related
We have some legacy apps on the Fabric dashboard though not sure if we'd ever needed them again so we could delete them from the dashboard.
If we do republish them, can we undelete them later?
If not, could we get another Fabric key to republish them with?
If you re-onboard the deleted app, by installing one of the kits, and building and running your app, it will re-appear on your Fabric dashboard. The historical data won't be available though. If you recently deleted an app by accident and need to restore the original app and data, we can help you out at support#fabric.io
I am testing WSO2-Emm system for managing our android mobile app. We have an app for taxi drivers. We deploy it using our tablets and a single gmail account. Our problem is that google allows up to 10 signed in devices for a single google account.
I have tried to load the apk to the WSO2 store. The problem is that when I want to upload a new version of the same app I get a warning message saying that this APK already exists in the store. When I try to rename it and add it as a new apk it works. The problem is that when I go to App-Management, the application appears under 'installed'. The Emm system doesn't detect there is a new version.
To be more specific, my question is is there a way to manage mobile application versions using the WSO2 store and not the google play store.
If there is a way we can go on with this system. If not, we will stop testing it.
The only way I've figured out how update an already installed app is by going to the App Management tab, selecting your latest version of the app in question, and hitting the install button under the Roles tab (NOT the Users tab). It will send the install command to any devices listed under roles you have checked, even if they already have the app installed. Keep in mind this will install the app on all the devices, even devices that already have the version you're trying to put out.
It looks like you already know about the patch on EMM-686 that must be implemented in order to upload multiple versions of the same app to the Publisher. Just in case you want to confirm it's implemented correctly, see my answer here for instructions on how to implement it.
How can I keep installation track of my app on particular iOS device? Actually I want to check that my app was installed on a device or its first time installation. I tried identifierForVendor but it got change on every install.
There are a couple of ways to do this.
Easiest would be to implement Google Analytics
If you have your own reporting, you could use a 3rd part library to identify the device its on and then send that info to you... such as:
https://github.com/QuickBlox/SuperSample-ios/tree/master/Classes/Helpers/DeviceHardware
I'm testing the implementation of the emm, and as i understood in the documentation i can
Automatically install applications WITHOUT end user intervention
Block any application to prevent its installation
Automatically UNINSTALL any app without end user intervention
I tried to perform this tasks using Policies but it didn't seem to work.
I'll appreciate your help.
Thanks.
Gabriel.
You need to configure WSO2 EMM in order to get it working. However for Android devices silent installation and uninstallation does not work until you install the Android Agent app as a system app in your devices. So it will prompt a message to user when EMM server perform an installation or uninstallation operation on the device. But for iOS it happens without use intervention.
if you blocking an app, EMM 1.0.0 shows an warning message to the android users to remove it. and for iOS it actually block the app.
You can use policies to block apps and install apps to the devices.
For iOS you need to configure it according to the documentation in order to get it working. For Android it works without any configurations, but if you are going for production you need to configure it.
I got around this issue by rooting the Android devices we're using and installing the Xposed Framework, along with the XInstaller module for it. There are several options for installation/uninstallation that can be used to create an installation/uninstallation experience free from the need for user intervention.
This was pretty easy for me to do, as we're only using corporate-owned devices that don't even leave the facility. Your mileage may vary.
I have created an application that exposes a OSX service for certain file by adding an NSService entry into my applications info.plist (as in http://www.macosxautomation.com/services/learn/), but I find that upon installing my application on a new machine the service doesn't show up quickly in the finder right click context menu.
I know that this is because pasteboard services hasn't re-indexed the /Applications folder and "discovered" the newly installed service.
I also know that I can force a re-index and discovery by manually running /System/Library/CoreServices/pbs.
The question here is what is the best way to ensure that my service shows up as quickly as possible for users who are installing my application for the first time.
I could execute a system call to "/System/Library/CoreServices/pbs" when my application starts up --If the user immediately starts my application--, but that only partly solves the problem (in addition I wonder if there is a better Cocoa API based way of doing this).
If my application is generally only accessed via the context menu, a user will never think to go out and start the application in the first place. They will only think it is broken when the context menu isn't there.
I am not distributing my application with an installer. I am simply providing a bundle that can be dragged and dropped into /Applications (as I believe Apple usually suggests).
Is there a way to expedite the process of service discovery when doing an installation in this fashion, so that there isn't any period of time where the user is without the newly installed service?
As a side note, it appears that the problem may not exist in 10.8 (or at least be as pronounced). Apple may have made this indexing happen more quickly in their most recent release.
I've actually ended up using
system("killall pbs;/System/Library/CoreServices/pbs -flush");
in one of my apps, just as you describe, though it's a long time ago, when 10.5 was in question as well.
You might want to try this function, however:
void NSUpdateDynamicServices(void)
which according to the documentation acts just like flushing pbs, but is a cleaner solution.
Also, if (according to your description), the app is nothing but a service, consider making it a really just a service - see (Installing the Service)
To build a standalone service, use the extension .service and store it in Library/Services.