I see that the BT_HTML directory is no longer included in the source code download, v1.5, and that custom HTML docs should now be included in the BT_Docs directory. If I download the source code again for a project that previously used the BT_HTML directory do I now have to move files in that directory into the BT_Docs directory before compiling or do I continue to keep them in BT_HTML?

Yes, move all files previously in BT_HTML to BT_Docs (in the physical folder AND in Xcode). And then recompile!

Thanks!

Yeah, rats, probably should have mentioned that. Yes, we've tried to make it just a wee bit less complex. In a literal sense, Xcode doesn't care what folder you put files, images, other assets, the folders are only there to make it feel more organized ;-)

I'm not making use of source-code implanted files, but I will eventually. I'd think the more consolidated, the better. Images, sound, video, icons, custom html, everything in one folder. Reason being, I can keep a local folder with all my assets, and copy the one folder into the source code. Quicker, simpler, better. Perhaps if you have the option to create your own folder structure within the single assets folder, that might be nice. Example: (BT_Docs being the base folder) BT_Docs/images/filenames.jpg BT_Docs/mp3s/filenames.mp3 BT_Docs/html/filenames.html and when you go to input your file name in the buzztouch control panel, you also include your path, eg. /images/filenames.jpg rather than just filenames.jpg. That way users could organize as much or as little as they like, and again, it's just one entire folder to add to the sourcecode upon download. I might even call the BT_Docs folder BT_UserDocs so that it's as clear as possible to users. Here's taking this one step further: Why not allow users to upload docs through the buzztouch control panel that then get embedded in the BT_Docs folder through the control panel, and they are already in the source code. You know I'm a proponent of uploading. I just think the less the user has to do within XCode, the better for buzztouch. To me, buzztouch is all about a user-friendly, it just works approach to making an app. Seems to me this is close to a core value for the service. XCode is not so much user-friendly or it just works for the non-coder. Now, using buzztouch and having to get to know XCode at least a little bit has been good, but challenging. I'm not trying to toot my own horn hear, but I'm not a dumb guy, and I really dove into it hard to get to where I am. I don't think the typical I want to make an iPhone app but don't have a clue person is really cut out for all that. I think buzztouch wants to attract and appeal to the less-complex user, with a lower level understanding of it all. I really see the potential for this to be to Apps what WordPress is to website creation. Pretty much anybody can do it with very little prerequisite. Anyway, the less there is to do in the process between downloading source code and deploying on a device, I think the better off for the users. Now this obviously requires more storage of assets on the buzztouch server and more bandwidth. So perhaps it's another possible feature that could be provided by a premium paid version of buzztouch. Actually, I think it needs to be a basic feature, necessary for all users, that's maybe free for a small amount of stored data, and paid for above a certain amount. So that's my 2.5 cents.

We are for sure with-ya on this and also understand the significance of spending our resources and time on helping non-nerds create something useful, good looking, and well-coded without any mumbo jumbo. Reducing the BS necessary 'after' working on the control panel is an important part of this. Including your previouly uploaded documents in a BT_Assets folder is logical and a good approach. One of the reasons we havn't implemented this (aside from unhiding the upload links) is the confusions many folks are having trying to understand how to update or change a file that is included in the Xcode project. Once it's included, the current logic looks for it and uses it. This makes it available for offline use but not available for updates. Hope this makses sense. Early feedback suggests that we may even REMOVE the ability to choose this option and force folks to make some sort-of complicated decision to allow for offline use. Blah, blah. Totally with-ya on this.

Yep, I get it. Also why I'm constructing without adding to or modifying the source code files so far. Making so many changes at this point it's just easier to change a Custom HTML page online and refresh my app and boom it's in there. Maybe have two options for downloading source code, one that keeps assets online (the default), and the other that consolidates to the source code, for a release candidate version for those that want it that way. Perhaps too complicated have two routes to code, but that's just an idea. (If I'm understanding it correctly.)

You're understanding it right. My thoughts on the best approach, and, the one we are working out... a) You visit buzztouch and tinker, play, tool around. Uploading files, pointing to files, etc, etc. b) You visit iTunes (or Android) and get the buzztouch Live app. c) You log-into buzztouch Live with your BT userid / password d) You browse your list of apps and test, refresh, play while making changes on the contorl panel (so far, no Xcode or Eclipse) e) When you're satisfied, choose a download option with embedded media, without media, and some other stuff Removing the Xcode / Eclipse dependency altogether, or at least until the very end will be ideal. There is alsy a VERY LARGE (overwhelming) number of folks that after doing this will just want to get the darn thing in the market. This is where we hope to marry BT ninja's with app owners. Still working out how that will work. Nearing completion on buzztouch Live and hope to get Apple's blessing. Apple rejected this concept a few years ago, with us, so we modified our vision until the landscape changed. It's changed (as far as we can tell) and do hope to get their support this time around.

Cool!! Hope all goes well...you guys deserve it...amazing work buzztouch

That's darn near perfect. I'd think Apple would be concerned that buzztouch Live doesn't become a gateway to distributing apps (circumventing the store) but just the portal for developers to work on development, that should be fine. Of course, you just never know with Jobs & Co. just what might happen. Seems to me they must have their own path towards easy app development for the masses, kind of an iWeb approach, but for apps rather than websites, but on the other hand, maybe not. I was just happy to see iWeb become what it was but at the same time see a niche for a higher quality product (RapidWeaver) that really survived the Apple competition, becoming even better through the process and appealing to a more advanced audience (but not necessarily too advanced). Despite some occasional heavy handedness, I think Apple does value real competition and apps/software/services that are truly focused on bringing the best possible product to market. And buzztouch seems very much to be this exactly. Now I've got to get back to making my fart app. ...JK!