Mark and I have finished a first version of the Plugin Market Checklist. There is a testing checklist and a files checklist. It is very complicated to pull a plugin together, I hope this will help! Here is a temporary link: https://www.dropbox.com/s/se9ftl7a83ko04o/Plugin%20Market%20Checklist.pdf I will get this on to the How To's page soon. In addition, David Book has a lot more information about the plugin market at this link: https://www.buzztouch.com/files/howtos/bt-plugins-creating-sharing-selling.pdf These will be key documents to help get your plugins to the market more quickly. Let me know if you have any questions or can think of additions to this list. In addition, there are a couple of key training sessions on plugins coming up at the end of January and beginning of February. These will be recorded, and will improve the instructions quite a bit. Thank you!

Thanks Susan!!

Great work! Thanks for the clarity!

Highly Appreciated, both of you! Cheers! -- Smug

We're really hoping this helps accelerate plugin development and approvals. By having a definitive checklist in place, developers should have all the items they need to get the ball rolling! Please don't hesitate to let us know if you need clarification, or if something just plain doesn't make sense. Mark

Looks great, very helpful. Thanks! Still hoping to see some language about 'scope' of expected plug-in functionality and what is expected as far as support. I have a hunch lots of the new stuff coming out will be 'moddable' so I'm wondering how much work a dev is expected to make so end users happy with the purchase? Every app is a different ballgame....

Some of this is an evolution of the plugin market, and so we don't have all the answers yet. There is no plan to require developers to submit for both iOS and Android. However, by the end of the year, I hope the market offers a lot more choices for both iOS and Android, because that is what a lot of users want. I will be making efforts to move the market in this direction, although I am not sure how I will accomplish that. I switched my own programming studies to Android...not because I prefer Android, but because it is what buzztouch needs. I also believe that for buzztouch to reach the world, we need to have a stronger offering in Android. In some entire countries, iOS has very little foothold due to the higher cost of Apple products. As far as support, do you mean buzztouch support for developers? My thought is that, at least for the most part, the focus will be on training everyone rather than completing the work on a plugin for a developer. I would love to see some partnerships emerge as well, because it is very difficult for a buzztouch developer to know Android/Java, iOS/Objective C, and web programming well. Maybe we will see some specialization combined with partnerships. It will be so much fun to see what we all can do with this market! I can tell you that some of the plugins in the works are much more complicated for users to implement, especially for new users. That is totally fine, although we should mark those as appropriate for "Advanced Users". Otherwise the user may not be satisfied. However, for those of us who are comfortable with more advanced plugins, we will have some really cool new options. We want buzztouch to be the place to make apps for advanced developers as well as people with little or no programming experience.

Here's one to add for Android- Specify the install location - Internal/External add to your Androindmanifest: android:installLocation="preferExternal" or android:installLocation="allowExternal" I'm realizing now that some of the issues people are having with the AT53 Video Plugin on Android is related to this. No space on the internal storage and they are not adding this to their manifest. You can't play a local stored video if you don't have space to store it! I kinda think this almost should be the BT default - "preferExternal" >>> As far as support, do you mean buzztouch support for developers? No. David/Buzztouch support is top notch. Beyond helpful and insanely responsive. I'm thinking some basic guidelines developers\purchasers can agree on. Such as how long to respond to support, how much of it when dealing with non-coders that are trying to use the code. I've seen it here - people buy a plug-in, sell the app to a client and then run into issues getting the code to work the way they want.... or maybe iOS 7 comes out and your plug-in stops working..... Once you stick a price tag on some code, the game changes. dev's need to weigh support time/avaliability into the whole process. (at least I know I do with so much going on currently...)

So true! That is a big issue we all have to consider. There can be a lot of service work on a plugin, and creating an upgraded version is a lot of work.