Publishing an Application

When you mark something as beta, only you can download it and it never get's approved (it's because the garmin guys had a bunch of "do not approve" apps before and they had to look at all of them when doing approvals.). There's no way that you can give users the ability to download it

See this Blog Post for more info.

Thanks Jim. I can't seem to get to that link you posted. Seems a valid link https://developer.garmin.com/index.php/blog/post/connect-iq-beta-apps but nothing displays.

So do you suggest a new application and mark in the description to contact developer before downloading or roll the dice and publish it as an update to the existing application in the store ? :)

The link in your post works fine for me. Her's the text:

The Connect IQ app store is introducing a new feature today: beta apps. This feature allows developers to test app settings and Garmin Connect integration in production without releasing the app.

Uploading a beta app will let you stage your app in production. To use this feature, you will need to create an alternate app id in your manifest using a UUID creator. Beta apps will show up in your uploaded apps, and you can download them to your Garmin device. Once downloaded you can edit app settings in Garmin Connect Mobile and Garmin Express, and test your developer fields in Garmin Connect. Once uploaded, you can update the beta version as many times as you want. When you are ready to release the app, change the app id to your production version in the manifest and upload it without checking the “Beta App” checkbox. Note that the app will have a separate store identifier from your final app, and URLs to the beta will not be visible outside of your account.

As far as how you handle testers, that's really up to you. Is it something where you could just email a sideload?

When you upload a beta app only you can download it (the only use I see is that you might be able to change settings with garmin express/mobile app, not even sure if that works) but other then that it's not really useful to be honest. The only real way to test is to publish it and put in the description that it's in development and ask the users to contact you first in case of issues.

If you don't have any settings in your app you can sideload it, but when users can change stuff (custom fields in a watchface for example) it becomes kinda useless because the user can then not change any of those settings.

To be honest, I really don't like this aspect of connectiq (because many users simply give "1start not working" reviews when something is wrong) but it is what it is...

For me, I won't put anything in the store that can be downloaded by everyone until I'm really sure it's working the best I can get it and not a development version.. We all know that users often don't read the description. :). If something doesn't seem quite right to me, or something isn't complete, I don't publish. There's really no deadline to first publish. The use of shared code/barrels helps here, in that you can be using a fair amount of tested and proven code. (app settings for all my watchfaces is common code, as is my code for watchface data fields, so something I don't really need to think about).

While some users don't mind alpha/beta/development versions, my gut tells me that most users except it to be more of a finished version (no matter what it says in the description.:) ), and if they get a buggy version, it may result in a contact developer messages/bad reviews, but likely will mean they'll just uninstall and not come back. (soapbox off!)

For early versions you really want in the store, you can kind of obscure it a bit so only people that knows what it is (and it's state) will download it. Things like using a blank image for the main image, and giving it an initial name that really says little. "Under Test 765" or something. Both these things can be changed when you're ready to "go live". Also, some of the best people to test are other developers, where sending a sideload with debug symbols and possibly a .set file can really help a great deal. You have someone that understands what to do with a sideload, how to create a log file for it, how to get a ciq_log file (with debug symbols and a real stack trace), etc. A knowledgeable "eye" to see what's happening. One person like that can be worth more than a whole bunch users in the store. If you're looking for that kind of help, just ask in the forum, and be ready to return the favor :)

May I suggest that instead of using "development version", it be something like "initial version (use contact developer with suggestions)"?

Development version means bugs to me, and "send suggestions" is more "tell me if you don't like the way it works, the font is too small, etc". (I still get suggestions on things I did a couple years back, and those things are NOT a development version :) )

What you can do is do the settings in the sim and then send the .set from the sim's temp directory along with the .prg. The user can't change the settings, but will use what's in the .set

Another thing you can do is upload the app to the store but provide a password setting which requires the user to know a magic word providing actual access to your app. When starting the app without the setting filled in you do nothing, when starting the app with the correct magic word (eg open sesame) filled in you do the normal behavior. A simple if should do it in your code ;)

It's not hiding the app from your non testers, but it's an approach that seems more practical to me...

I like sideloads and .set files, as that way the user can run a .prg with debug symbols if anything goes wrong, and the name of a log file is simple to know if data needs to be collected. And not a single line of code needs to change. I've sent these to folks to test, and others have sent these to me when they want a test (no, that is NOT an open invite! :) )

But to each their own...