To resolve the update problem Mark points out, I suggest/agree that the problem is not everyone updating their app at the same time. Pointing config file initially to Dropbox seems to solve this problem. Perhaps a change in the Control Panel as follows: Add option in core properties in Control Panel to: a. point to Config file on Dropbox, (or better yet option to publish or not publish changes to the Config file: Copy of Config file as a user specified point, example User fixes config file and any changes in the Control Panel subsequent would not be reflected until user published the Config file update.), and b. Reconfigure the Report to Cloud URL to reflect option a. above.) This would eliminate need for Dropbox, not that I'm against Dropbox, but would simplify process for Buzztouch users. Down side is that Control Panel would have two config files and additional options lead to user overload and confusion, but in this instance I think it would solve a bigger problem. Fred www.MySkylla.com

For sure something that's been discussed and like you mentioned there are some trade-offs as far as understanding how the system works. My vote is for a "flag" of some kind that is set to "Live" or "Design View." While an app is in design view the changes are not propagated to the actual config.txt file that powers the app, only to the control panel. In order to see the "Design View" changes in the device the app owner would set a flag in Xcode or something, like "isDesignView":"1"

Yeah, I like that idea, David. If there was a way to signify that new content is in a design stage, that would totally solve the problem. A user could then publish an app, put the control panel into design mode, and make changes that are only visible to them. Then, when all is ready, flip the switch and let 'er rip! Mark

Maybe like a big red banner or box around the thing while in design mode? Need to make sure it's very obvious and a graphical indicator seems right. I think more than anything it should be "all or nothing" and not design / live on a screen-by-screen basis. In other words, the entire app is in live / design view or it's not and when it is it's easy to see that for the app owner.

Yeah, I think you're right. And I think the "isDesignView":"1" part needs to be at the top of the config file, and it gets processed first. If it's set to 1, then we're in design view, and no further processing of the file should occur, defaulting to the cached version. If it's set to 0, then proceed as normal.

The design view Config file should be available for copying / download to allow a developer to create an app for testing prior to publishing. Or have a separate link that the developer can use for testing / development. Fred