I am nearly done with my first android app and there's still a bit more work to do but I want to get feedback from users about what they like/hate/bugs to fix, etc. I plan on making the app free with ads. Now I have been testing my app on my phone (HTC Magic) and plan on doing some simple testing on the emulator using different configurations. Would it be a good idea to release the app as being beta as it is now? And then fix up any issues and implement the full features I want in it later on and re-release it? I don't want the beta ratings to hurt the final version so would I'm guessing I simply release it as a new app instead of an update to the beta?
Also If I was to release the beta should I be releasing it with or without ads?
I would love to hear your experience with your apps!
Thanks
In this kind of situations, that's exactly what you can try to do: release a beta version of your app so that the bugs don't hurt your rating on the Market. What I prefer to do in this kind of cases:
Don't add Ads. After all, it's just to be a testing experiment. Not too many people is going to download your app.
Offer a bounty for people who discover bugs. For example, you can give a free fully functional copy of your app to the people who helped you find bugs.
Use a Log system for Android that automatically send you reports of your app.
Try to make sure your app will be tested on different devices with different screen sizes, configurations, etc.
Once you have fixed bugs and done the appropriate modifications you can go ahead and share your app with the whole world.
Don't push half baked product in android market. To get feedback and track crashes do a beta distribution. Try Zubhium , simple yet powerful platform for android dev's where you can upload apk, distribute to users. Optionally, you can enable crash reporting to get realtime crash reports and enable in app support using ZubhiumSDK to your market version. That way you are giving your users a outlet to express their feedback, comments, feature request etc.
Related
I've recently published my very first app to Play Store. I asked a friend to download and test it and it crashed on his phone. However, I have an exact phone as him with the same version of Android, and when I tested it the app runs without error. So what do I need to know about a device to re-create the bug?
So I've just figured out that Google Play Console there is a feature called Pre-launch report which give you the log of the bugs from user's devices, it is under Release Management tab on the left of the web page.
If you are a developer then can not re-create bugs because you would test with best-cases of app.You should test with worst-case scenario.
I will recommend to use a professional Tester to test your application. He/She must find out the bugs.
I am going to have a alpha release of my app, which is not yet on the market. I want to have the app APK link sent out to friends via email so they can download it from my site CDN.
One question here: if I want to give them updates, what will be a good way? Can I download the new APK within the app, and somehow install the APK to replace the old one without anything to do with the market? So my friends can have the app upgraded while it is still in alpha release?
When I did it, I used Zubhium -- they were a web service with a small API that you could install into your app, giving you a mini "app store"-style backend and handling distribution for you. It would host and distribute your APK, connect up to their server when the app launched, check for updates, invalidate old versions, gather crash logs for you, etc. It was very good.
Zubhium are now https://www.vessel.io -- I presume they still have the above features as part of their now-much-bigger service, but when I checked you had to give them a credit card number even to sign up for the free plan, so I've not played with it.
A friend of mine uses http://testflightapp.com for iOS, and it looks like they have an Android version now, so that's certainly worth checking out. A quick search also shows up http://applover.me. #Janusz recommends http://hockeyapp.net/features in his comment.
As #Nanne points out in his answer, the Play Store itself now lets you distribute to limited alpha- and beta-test groups. That looks like it has fairly minimal features compared to the third-party services (no A/B testing, etc.), but will be familiar and free. And it doesn't need an extra SDK rolled into your app.
So, my general answer is that there's more than one professional beta-testing API/service that you could use, that they're generally very useful, quite easy to roll into your app, solve all the problems you're anticipating and more, and often have a free plan to get started. I'd recommend picking one of them rather than trying to roll your own solution.
If you want this only to be able to release your app in Alpha, and maybe later in beta, take a look at the android market again.
Check out this link: https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
It boils down to the fact that you can have an Alpha-test, and a beta test, each with selected users. You can upload your app as normal, so you'll have updates via the market, but not everyone can download your app.
For the beta at least, you can select a community that is the source of your users, so all that are in that community could be testers.
This is the best method for testing I believe.
Now I've nearly finished my first app and I wanted to have two versions of it, one free (with ads and a little less functionality) and one full/paid version.
I know that you can not completely prevent apps from being cracked/distributed, but anyway, I'm currenlty having some thoughts about what the best method would be to release the app.
1) Both full and light versions in the store with no additional checks
2) Full version with Google Market license check integrated... Does this really bring any "security"? I've read that this protection has been cracked and therefore is pretty useless?
3) Have the light version and convert it via InApp purchase to the full version? Currently I have no idea on how to implement InApp billing and how to check whether a user paid inApp to release the full functionality and... of course there are also ways around that, right?
How would you do it?
Do you try to prevent your app from being illegally shared, or do you think it's not worth the effort, as any protection can be removed (and then it's shared anyway)?
Just gathering some thoughts :)
I have been through the same thought process and settled on option 3 for new apps.
My reasoning is as follows;
With option 1 you have two apps to maintain, users have to do a uninstall of your trial version and you have the problem of migrating data between the two versions.
Option 2 has all the problems of option 1 plus the headache of implementation.
Option 3 you have the benefit of only one codebase to maintain, users can quickly and easily upgrade with all their data intact and you have higher download stats/ratings for the one app rather than two.
Implementing it has got a lot easier with the version 3 of the billing library. I followed the sample from Google here and got a simple remove the ad's with IAB within a couple of hours.
I personally think that an In app purchase is the most secure way to stop people from getting free paid versions of your app, because when someone inevitably (if your app is popular) release an apk file of your app on the internet, it is just the free version.
I'd like to publish an app in the market to make it easy to install, but we're in early beta, so I'd like to prevent random people from stumbling on it and likely giving it a bad review because they can't log in (or whatever). Ideally, it would hide the app, unless you had a direct link to it.
Any way to do this? It looks like you can prevent outside advertising, but I would assume the app would always show up in market searches. You could set the maturity level super high, and try to lock down geography, but this all sounds like a bad idea.
You can go someway to 'hiding' the app, and dissassociate the beta from the full release:
use a secret name, so the app won’t be ‘stumbled upon’
use a separate market account
don’t fill in the description
give the app an expiry date
give the beta a different package name from the real app - this will ensure low reviews don’t get carried over to post beta versions
Have a look at HockeyApp. They provide a hosting service which allows you to make your builds easily accessible to invite-only testers, upload new versions automatically from your build scripts, and with a few small changes to your app you can get it to auto-update on users' devices.
On top of that you get nice error reporting.
I use it for distributing my beta builds, separately from the production-ready release builds which go on Google Play.
Just an update - the answer for most people will now be Google Play's alpha/beta testing & staged rollouts.
I would like to distribute a beta version of my application to a small group of users. Ideally this would be done through the market to make it easier for the beta testers.
Is there a way to restrict an app's presence in the market? The only solutions I could come up with were:
1 - Have users download the .adk from the web and install manually
2 - Release the beta version as a separate app in the market
The first option isn't ideal as you have to potentially walk the user through allowing apps from unknown sources. Not to mention from a user perspective, you're then downloading an app from an untrusted source.
The second option isn't ideal as you then are potentially confusing other users by having multiple versions in the market, one of which might be flaky. And then there's the inevitable comments about how something doesn't work in the market. I guess you could add some sort of password to that version that you only distribute to your beta testers.
Are there any better solutions?
Market is for public apps only so there is not any good ways to do this. Our app was distributed by email as apk when we where doing beta-testing. Use android forums to get beta-testers.
But, if you insist on using android market. I suggest re-name your app and package-names, and put it into the demo category. But again, I would not used android market for beta-testing.
Perhaps put a relatively high price on it and refund the beta users' money.