Hi All, There was a discussion back in August about the App refresh on first download from app store http://www.buzztouch.com/forum/thread.php?tid=31BDD834EEC37EFFA5712FB The last suggestion was...update the App store with your v 1.1 I'm working with a client who will be updating the Home screen format frequently, so constantly updating the app store isn't an option, and trying to explain to a new user make sure to hit the update button the first time you use the app isn't an option either. Arrgh. Is there some architectural fix, for example, some way to force the BT_config.txt file to update the first time the app is loaded? Some way to REQUIRE the use of remote server BT_config.txt? From my perspective this is a huge issue, because it speaks to the potential for highly dynamic app content. Apologies if this is already covered elsewhere and I missed it...

I think to copy your config data in Show App's Configuration Data screen and paste it to your project's config.txt before submitting is the answer.

Ninjaselo, Hmmm, my home page content changes almost weekly. So if I understand it properly, your solution would require me to re-submit my app weekly. That would would not be practical unfortunately.

Only submitting once with the new config.txt file can resolve your issue. David can give a better answer to you.

OK that's interesting. I'm not sure if I understand how this work...will try to dig into it. Thanks!

Hi ThomasB, Anytime you make changes to your control panel you end users will be prompted to update their app. They will be notified by a small popup window giving them the option to either update or not. Another idea would be to have your screen with the frequent changes draw its data from a Data URL. A file at this URL would provide that screen with JSON data to build the screen. You could just update that file as you need to make changes.

Hi Parker, Yes, but the point is..that doesn't happen for a newly installed app. It doesn't prompt them IF they just installed the app. Upon first install, the home screen just blanks or shows a subset of the menu options which don't work. It only prompts them if the BT_config.txt file is updated on the server, AFTER they installed their app. This was discussed in this prior thread...http://www.buzztouch.com/forum/thread.php?tid=31BDD834EEC37EFFA5712FB. The final answer was: always update your BT_config.txt immediately before submitting. But, for apps with content that changes frequently, that isn't possible. So what am I missing here? Thanks! PS. I did read the 1.5 docs which describe the BT_config.txt update process, and looked at the diagram that GoNorthWest posted at: http://www.buzztouch.com/forum/thread.php?tid=83CD403BD9164F7BE681C4C&status=&searchInput=config&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=1&doViews=1

Ok, I found a thread where David explained how it works. (The Forum continues to be the amazing resource, if I can find the right search terms) I guess the bottom line is, when the app is first activated on the device, it will never refresh to go get the new bt_config.txt file from the server. That's the way the version date for the config file is checked. ------------------------------- >When the initial check happens (after AppStore download) what date is that compared to? Creation date of the BT_config.txt file? >Nope...when it checks for the first time, it doesn't force a refresh because the 'last saved date' is not available and it uses the configuration data in >the BT_config.txt file, downloads the last modified date from the server and saves it. >The next time it loads it will then re-download the last modifiied date and do the comparison. The app saves a file with the last modified date it it's >cache. The file is called appModified.txt. You can see this file in the simulator. My comptuter saves simulator data files >here: /Users/davidbook/Library/Application Support/iPhone Simulator/4.2/Applications/[the app id]/Documents >Yours probably does the same thing. Have a look at the contents of appModified.txt after the app downloads it, this is the value returned by the server >at reportToCloudURL. Your reportToCloudURL can also include devices variables (merge fields) if you want to save information about the device's location, >model, and other things each time it 'reports to cloud' -------------------

A lot of my apps use a rss screen for the first screen. Content always changes and is always current with the first install. Perhaps you can make your content pull from a rss feed.