Hi, I'm wondering how to approach a version update to an app that is already in the iTunes store. I currently have an app in the store that I can see adding some new screens to and changing other things around in...it would be a version 1.0 to 1.1 sorta thing. The problem I see, however, is that if I mess around with the app in Buzztouch, anything I do gets replicated to the apps already installed out in the wild! So, people would see a constantly changing app, and that would not be good. I thought that maybe if I disabled the Report to Cloud URL or Configuration Data URL, that would prevent users from seeing changes to the app. But, if I disable those, then don't I effectively take the app offline, meaning it won't refresh when smaller updates are made? And, if there are pages that haven't been accessed and cached for the first time, users would never see those either (if I understand how it all works). So...any thoughts on how to do this? I could imaging creating a new app project in BT...say, v1.2 of my app, and making changes to the .plist file, but I'd then have to create all the screens of the app from scratch. I'm confused on the direction I should take on this. Any suggestions would be appreciated! Thanks, Mark

Hi Mark, With the Report to Cloud and aData URL set to default, users will see changes you make to the app whenever they refresh the app. They will be prompted to do so when the app is loaded anytime a change is made to the control panel. Disabling the Report to Cloud and Data URL options means that users will only receive an app update notification if you resubmit an update to apple. Users wont be able to refresh when small changes are made. This will NOT affect the end users ability to visit screens/pages within the app or outside URL links. Another option is to change the URL for the Report to Cloud and Data URL settings. You can change it to a location hosted online that you would manually update whenever you want your users to refresh their app for updates. The end user won't see any changes you make to the app control panel until you are ready for them and you update the files at the URL yourself. Generally this is something an app developer should consider before releasing the app to public, but it's by no means the end of the world. You still have flexibility in your options. Take a look at the Documentation section covering the Report to Cloud and Data URL settings for some more detailed information.

Hi Parker, I do agree that this is something I should have thought about before I released the app to the public. I think I was so excited about the possibilities that such a thing just slipped my mind! But it's there now, and is a consideration for all future development. Thanks for clarifying the role of Report to Cloud and Data URL features a bit. I have read the documentation on them, but sometimes the exact details of the feature get a bit lost on me. Maybe because most of the time when I'm reading it, it's like 2AM or something! I did want to clarify one thing. You said that This will NOT affect the end users abiloity to visit screens/pages with the app... when I disable the Report to Cloud and Data URL options. Does this hold true for Custom HTML/Text pages as well? I see from the documentation that such pages always require a trip to the BT servers in order to server up the screen's content. I just want to verify, for sure, that if I disable Report to Cloud and Data URL, that EXISTING Custom HTML/Text pages will still be viewable, even if they have not already been visited and cached (which I also believe is a feature of that screen type). Please confirm. Thanks! Mark