I am making an app for a local film festival. There will be important last minute changes to the schedule. Complicating this, the attendees at the film festival will likely download the app at the event, and because they are downloading for the first time they will receive the config file as it came from the App Store rather than the most current config file. For Android, I will just republish whenever something significant changes in the app. But for iOS, do any of you have ideas on how I can force a refresh to the app when it is first installed or shortly thereafter? Here is a previous forum item on this topic, and based on this it appears that the problem cannot be solved without risking a bad experience for the App Reviewer. Here is the thread: http://www.buzztouch.com/forum/thread.php?tid=B2FA3F50B3F917B01EF1FA7&command=isSearching&currentPage=1&topicTitle=app%20refresh&createdBy=&repliedBy=&minViews=-1&maxViews=-1&minReplies=-1&maxReplies=-1&forumCategory= My backup plan is to include a splash screen that asks users to hit the refresh button, but I prefer to use that as a last resort. What ideas do you have?

Could you just put updated info in a rss feed? That would always be current in the app.

BTv2.0 or BTv1.5 ? There will be important last minute changes to the schedule. Use (with force refresh) Custom HTML / Text HTML Doc (via URL) Launch Native App (Browserm Complicating this, the attendees at the film festival will likely download the app at the event, and because they are downloading for the first time they will receive the config file as it came from the App Store rather than the most current config file. True no matter what you do. For Android, I will just republish whenever something significant changes in the app. But for iOS, do any of you have ideas on how I can force a refresh to the app when it is first installed or shortly thereafter? Why the difference, the Config file works the same in both? RSS Feed is a good proposal. Regarding the update problem: Random & frequent saves to Control Panel will cause the app to refresh whenever the user go to the "home" screen the second time.

Thank you, Fred and @MGoBlue! I have been meaning to learn more about RSS feeds. The RSS feeds work for the future too, as this app will have the same problem every year. I have been studying web programming a bit, and this would be a good challenge. If that doesn't work then I will set up the the schedule information with a custom html screen. The difference between Android and iOS is that it is very simple (and not at all risky) to republish to Android. For iOS, if I refile with the App Store, I have to wait a few weeks for the new app to be re published and the reviewer could reject it. Would a custom url work as well as a custom html screen? Would they load at the same speed, or would the custom html be faster? With the custom url I could use some javascript, and I am not sure I could do that with the custom html.

Would a custom url work as well as a custom html screen? Post html doc in Dropbox & link with: Custom URL or HTML Doc Would they load at the same speed, Yes, but that's a guess since I've not tested it. or would the custom html be faster? Don't think so. With the custom url I could use some javascript, and I am not sure I could do that with the custom html. You can with Custom URL & HTML Doc I believe you can with Custom HTML /Text but not positive.

Hi Susan I tested this for myself a couple of months ago and I recall that anything you change and save in your control panel for an app will trigger a refresh. The first time the app is installed and loaded, it does not do a refresh. The second time it is launched, it does do a refresh check. So if you have any changes made from your control panel since submitting to Apple, the whole app will refresh anyway on second use. On that basis you may not need to do anything else to trigger a refresh, but you might want to make the user aware in some way. Alan

So if you have any changes made from your control panel since submitting to Apple, the whole app will refresh anyway on second use. That's the rub, it's not any changes "since you submitted to the app store" but "it's any changes since the app download". App is published. Make changes in control panel & save App is downloaded User opens app No notice to update is triggered User opens 2nd time No notice to update is triggered After app downloaded A change in the Control Panel is made & saved User opens the app for the 2nd time A notice to update is triggered. So, how do you know when user has downloaded the app to make a "save" so the app will update on 2nd opening? You can't know this without the app reporting this. But either way seems very labor intensive to do, question is how to avoid this. Solution would be to have the user update the app upon opening. Splash Screen tells user to update. User updates. New Config data is stored in localStorage New Config data now has different image (2nd image) used in Splash Screen App uses new Config data. User opens app see 2nd image when Splash Screen displays. Problem solved. So, package app (binary with instructions splash image) Make modification in Control Panel to Splash Screen to use 2nd image. Alternative is package binary without using Instructions Splash Screen Image Have opening "Home Screen" be a Welcome & How-To use app screen. The home screen informs user of need to update. Especially due to dynamically evolving events such as a Music Festival Then after the binary is created, replace the home screen Add Splash screen of you wish (could be done before the binary was created, it makes no difference) When user update initial home screen is gone & new home screen is displayed. New Config data could move "Instructions Screen" to a help section or delete it entirely. Apple may reject app due to use of "placeholder text" in app. You then need to explain to the reviewer that it's not "placeholder text" but instructions. If the instructions are well written it shouldn't be a problem. The app should function and flow well as packaged. The reason app with old Config data are rejected it's not that the Config data need to update to deliver current info, but their rejected because the Config data packaged in the binary is to a partially built app. Fred

I'm quite interested in this issue, so I did a little test. I loaded an app onto my phone that I knew I had modifications that I would see when a refresh was triggered. Fred was quite right, it isn't the second load that triggers the refresh, it is change after the app is loaded that does it. I went into my control panel, opened a html/text page, saved it without changing it and then when I opened the app again and asked to refresh. That might give the right result, but is a bit manual and I guess that is not quite what you want. I also noticed that if you use custom URL's to link content, when you change the linked content the app doesn't trigger a refresh, but when a refresh happens, the linked content updates then, which might be another reason to want to trigger a refresh. If I understand correctly, @MGoBlue's idea triggers a refresh when the RSS feed content changes. If so, then that gives a clever way to make an app update that I had never thought of before. However, if people would be downloading the app at all times of the day and night, would you need to update the RSS quite frequently to make the idea work? And if you did that, is the down side that the app says there is a refresh needed when it isn't? I like Fred's idea a lot, I didn't realise Apple would allow it.

I also noticed that if you use custom URL's to link content, when you change the linked content the app doesn't trigger a refresh, That's because you hit the "Save" button. When you download the app it has no timestamp. After the download the app gets the timestamp of the last update. (Use of save button) App compares the timestamp and concludes there's no update. This happened because the timestamp the app acquired is the same timestamp its comparing to. If the app had the timestamp of the last update as of the date of the app binary was packaged the problem wouldn't be there. Any change to the timestamp the app acquired after initially downloading will trigger the update process because it has a new timestamp with which to compare. Fred

Do you think I could have problems with App Store approval if I include a reminder on a Splash Screen to refresh the app?

Perhaps, since it indicates the app is "not finished" and using "placeholder" text. By having the Splash Screen switch I don't think it'll be an issue. But ultimately I think it'll depend on the wording. Perhaps something like, "For the latest Buzztouch Music Festival news update this app frequently since we're adding content hourly". Fred

I checked with the festival organizers, and no RSS feed available for this year. I think I will use the splash screen idea. After the app is published, I will change the splash screen to another as Fred suggested. That way the first time the user opens the app (and until a refresh happens) the user will see the request to refresh in the splash screen. After the refresh, the splash screen will be generic. The splash screen could also hold last minute changes.