Hi David - couple of questions, if you can help. 1)When using an 'HTML Document' screen rather than a 'Custom HTML' screen would I be right in assuming that any changes to the document, post uploading to the app store would require an app store update and would not change automatically as other screens do? 2)If screens are updated by me will the end user have to manually refresh the app to see those changes? for example if they never refreshed the app would they only ever see the data as it was when they downloaded it or would it refresh if a data connection was available? Hope these make sense?!

1) HTML Document Screen: You have two choices here. If you drag a document into the Xcode project, it will load very fast, and be available offline, but will not be updatedable withou an App Store update, like you mentioned. These types of screens are good choices for non-dynamic content. However, if you use a URL for the document, instead of a document name, it will be updateable from your control panel. The performance isn't too bad but does require an internet connection. You could also put a Refresh Button in the toolbar to signal to the user that the content is coming from a URL. 2) This depends. There is some logic built in to try and update content without user intervention but it really does depend on lots of things - one of which is what type of data they are looking at. Images, pdf, html, sound, video, etc. etc. Complicated! The Refresh button on the home screen deletes ALL the cached data so everything will be forced to refresh. Other screens can also include refresh buttons in the toolbars. When refresh is tapped, and the apps configuration data is downloaded, a file is saved locally in the phone that includes the 'last refresh date.' The idea is that we could evolve this to handle some sort of automatic updates down the road. Not totally sure how this would work yet. It will likely end up being a combination of the 'ReportToCloud' logic and the last-refresh date. If the app is reporting to the cloud, it's logical that it could 'learn' if there was content that needed updated. Again, compilcated stuff. Hope this helps and makes sense.

Thanks David, In v1.4 there was a 'check for updates' function performed which returned a message notifying the user that the data had changed and to prompt them to refresh it. Is there a reason why this is not in v1.5, could it be added?

Another question on this subject! When adding a 'Refresh' button to the toolbar (right button) I can only seem to set it to load another screen, not to actually refresh the current screen. Is this right?

Second question first: Yes, the top-right-button will always lead to another screen. The options for the different types of buttons are there because the 'next screen' could be about anything so we've given plenty of options to choose from. First question: The Refresh Logic (for the entire application) is designed this way because folks are running the Sim. while they design and there needs to be a way to constantly force a refresh after making control panel changes. 'Asking to refresh' seems logical but lots of folks complained about this. We're still trying to figure the best way to do this. Because there are so many options now, it's tough to know what the best approach is?

Thanks for your response david - I totally understand that with something like this it is almost impossible to find solutions that suit everyone. The great thing I am finding with v1.5 is that it is so flexible that it is nearly always possible to get where you want it to go, one way or another. Also very often having to think about it a bit more leads me to a better solution. Keep up the great work it really is appreciated.