As I understood, it is possible but such applications are not allowed in the official stores.
The app should get permissions in advance, from the user, and then, at random times, send an SMS to a random user from the phone contact-list, without further user interaction.
My questions are:
1) Is it possible at all?
2) If so, is it something that the official stores will approve?
1) In Android this is possible. If I recall correctly, there is no API for sending sms in iOS, without going through the stock sms application.
2) It's sketchy... Apple would probably not approve this kind of application, if it's even possible to make in iOS. Its never a good idea doing things behind the users back.
Apple will definitely NOT approve this kind of app!
I have tried this for over 2 years now, even contacted Apple - there is no approval for this!
There has been an App in iTunes at sometime (how that could have passed the review process - nobody knows) This has been removed as soon as Apple got to know about this.
Besides the approval issue, there is no OFFICIAL way to even accomplish this.
While there are/were some direct calls to private libraries, using these would immediately be identified (even automatically nowadays).
Just stick with Apple's rules if your App allows - give the user some background information, why they need to explicitly press "send" again - otherwise you might get some bad reviews, since this fact is certainly not known among all iPhone users.
In Android this is just a normal usage of SmsManager.getDefault();
Related
I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.
With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.
For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.
When developing Java apps used internally by users in the company I work for, I would have the app display a message such as "An issue occurred. Please contact the Help Desk and report it", when an issue occurs with the app that is being used.
Now that I am learning to develop mobile apps on my own, I am faced with the question of how best to handle app issues in this environment, since there really isn't a help desk.
My initial thought was to asynchronously call a service to log the error. But, remote communication may not be possible. Then, I thought to display an error alert with a number to contact or e-mail address to mail to report the issue. But, is that really best practice?
So, for mobile apps, what is the best practice for capturing issues or having users report them, so that they can be properly addressed and not have them become very frustrated with your app, especially if the root cause may be related to something that is out of your control, such as an issue with a godaddy server, which hosts a database used by the app?
Thanks in advance
For recording crashes, you could use Crashlytics, so that you can see the device log when that crash occurred and investigate the reasons to improve your app / prevent the crash from happening again in the future, or reaching out directly to the specific user (as you could record user id / email addr in Crashlytics) if you for instance see the app crashes for her/him repeatedly.
For issues/problems the app experienced (but it didn't crash), you can use things like Rollbar to record the incidents. You can put special logic in your app, especially places that are prone to failure, or whenever your app recognizes "an issue".
If you want to have a place in your app that users could search for FAQs, ask questions or provide feedback and concerns, you may want to use things like UserVoice to provide a central hub.
[Things aforementioned may not be free software.]
You can use Crashlytics and if you do not want to go for third party then you can read all of your logs from iOS SDK for your app,so you can go for it as well
or there is always solution with third party softwares
I am developing an app that has to access user's contacts to perform certain operation automatically for the user. But how do I prove it to the users that the app isn't doing anything its not intended to do...obviously without showing the actual code, so that he/she is fully satisfied?
The most important thing with trust is likely to be the permissions. Users are more likely to trust your app if the app doesn't require too many permissions. Particularly things like read & send sms but generally the less the better.
You should also consider adding a privacy policy to the Play Store listing. Perhaps make reference to this in the app, by way of dialog or link.
If your app has to use contacts try and minimise anything else it uses. Also, perhaps let the users select which contacts are used?
As a final solution you could try showing the user a sample of the data you're using.
Lastly your marketing could specifically tell users of your intentions and reasons.
Hope it helps
My app is having success in Google Play with several million downloads. However, almost 50% of users have uninstalled it already.
I don't think that's a critical number but I'd like to find out why users uninstalls it, so I'd like to ask it to users using a simple form, only to the ones who want to answer of course.
Now problem is when to show that optional form. I've seen I can't use ACTION_PACKAGE_REMOVED because app that's being uninstalled won't receive that broadcast.
Of course I don't want to ever forbid the user to uninstall my app, but I do want to know when to start my optional form. Can you think of any idea how to do this?
Also, I've seen that Google Play asks the user why he's uninstalling any app and gives a few options (missing space, don't need it, ...). Is there any way to get those responses from Google, regarding my app?
If you can give me any other ideas how to investigate main reasons why users uninstall my app, to improve it, I'd be really thankful.
Once the user uninstalls the app, there's nothing you can do. 50% retention rate isn't actually that bad..
I would propose you look at how the users are using the app, whether it's crashing and how often it's being used: these can then lead as indicators to make an educated guess why they might be uninstalling your app.
Crashes:
These aren't always reported - it's only if the user elects to report it you'll see it in Google Play. Try Crashlytics for a more detailed analysis of how/when/why your app crashes.
Analytics:
I use Flurry to log events and work out what my users are doing. You could also look in to some A/B testing.
Any tips on how to implement a trialware model for Android apps? I plan to release my app as a free app that expires after 30 days unless the user buys the license via an in-app purchase.
I can use the Android Market API to tell if they bought the license, so my main question is how to prevent the user from un-installing and re-installing my app every 30 days? Can I save something to their phone in a permanent and reliable way that will remain on the phone even if they uninstall? I know nothing will stop a determined hacker, I just want to stop the average user.
I am also open to different approaches to going trialware on Android.
Thanks in advance,
Barry
Have you read the documentation on Application Licensing? Specifically, have a look at Implementing a Policy
I also have found this resource very helpful in determining the best way to get a unique ID for any one device. Android - Identifying App Installations -- They discuss pros/cons to the different approaches -- Straight from the developer's mouths!
I would avoid leaving unwanted remains of the application on their phone.
Instead, you can take some unique identifier of the device, and send it to your server, if this ID was not registered before, send it activation code, if it was, don't send it.
Store this activation code in some shared preferences etc. and when the application starts, check if the activation code is there and if it is valid.
They don't even have to uninstall, just clean app data. You can save something to an obscure location on the SD card, but that's also fairly easy to circumvent, even easier if they read this forum :) Your best bet is to have the app call home to your server and check if licensed periodically. That of course comes with it's own problems: do you allow it to run if network connection is never available, etc.