Here's an all too familiar situation that many users of buzztouch experience : You have an amazing idea for an app, and you've come across buzztouch where you realize it can finally become a reality! You sign up for an account, log in, and spend hours and hours crafting the perfect app. You get everything just right, package it up, and submit it to the marketplace. Your app is a huge success, and you starting thinking about the next version. You're going to make major changes to your app, but you don't want to disrupt your current users, and you don't want them to see anything new until it's ready. But you realize you have a problem - every change you make in your control panel gets automatically pushed out to your users! What is most of the time an amazing feature of buzztouch (immediate app updates) has all of a sudden become a concern because you didn't think about a strategy that includes app updates when you spent those hours and hours setting things up. As you finally sit down and think things through, you realize you're a bit stuck. What do you do next? Prior to starting work on any app, you owe it to yourself, and your users, to figure out how you will update that app in the future. But before you can do that, you need to understand a bit about your options, and what the differences between an online and offline app are. A lengthy description of online vs. offline apps, with various scenarios, can be found here: http://www.buzztouch.com/resources/Understanding_App_Refresh_and_Offline_Apps_v1.0.pdf Let's take a few seconds of our five minutes, though, and go over a brief recap: * ONLINE apps are those apps where changes made in the control panel are automatically pushed out to live versions of the app. This can be via a version of the configuration file on the buzztouch servers, your personal BT Server, or stored in some other network available location (like DropBox). Content like images, documents and HTML can be referenced from a URL in order to be accessible by your app, but can also be included with the app itself. In essence, your app has to be online in order to receive any updates you make via the Control Panel. Submitting a new version of the app in this case does not require an upload to the marketplace (unless you are including new, local content). * OFFLINE apps are those that have been disconnected from the configuration file in the way that online apps are connected to it. An offline app is produced with all (or most) the content and configuration file that it needs within the app itself, and no connection to the network is required. Adding new content requires building a new version of the app with the content included, and uploading it to the marketplace. Any by content, I'm really referring to new screens, and/or most media that ships with the app. On last thing to understand before we move on is that in both cases, you can reference content that is on the network. Your app configuration file can contain a resource that must be retrieved from the network, even if the app itself is offline in the sense that it always uses the shipped configuration file. What's really key here is that UPDATES to an offline app must be made through the appropriate marketplace, while they are immediate for an online app and do not require a new build. Does that make sense? OK, cool! So, at this point, you understand the differences between online and offline apps, and, if you've read the document linked above, you understand some of the various scenarios. The question you need to be asking yourself before you start work on an app is - what method is right for me? Let's go with the easy one first : Offline. If your content is fairly static - meaning, it won't change much, and you won't constantly be adding new content - than an offline app might be the way to go. In this scenario, all your content is included with the app, so no network connections are required. That means that all content is available all the time, no matter where you are. Both the Configuration Data URL and Report to Cloud URL are blanked out, so the app does no checking for updates at all. In this scenario, all updates have to be provided through the marketplace. I have an app, "AZ Fishing Spots," that was perfect for this method. I wanted to the content to be available in even the remotest of locations (think a lake in the middle of the forest), and I didn't want users to have to rely on a network connection at all. The information about these locations doesn't change much, so doing updates via iTunes was perfect for me. Thus far, this approach has worked out well. One awesome thing about having an offline app is that you can continue to make improvements to your app in the BT Control Panel, and nobody will see them until you publish an update. The reason for that is because the app is completely disconnected from your control panel, so nothing you do is visible to the outside. Cool! "Great!," you say, "That's all good and well, but my app has dynamic content that I want to keep adding to or improving. What are my options there?" Glad you asked! Your best option is an Online app, but there are some caveats to be aware of. If dynamic content is your goal, then the Online app approach is probably best for you. In this instance, your Configuration Data URL and Report to Cloud URL point to either the BT Servers or some other location, and each time the app is launched, brought to the forefront, or a manual update requested, the app will query the server for updates, grab them if they exist, and download them to the device, caching it for later use. This is the brilliant part about what buzztouch offers! You can literally push changes out to the millions of users of your apps at any time of the day or night, simply by making changes in your control panel. How amazingly cool is that! Add a new screen? Bam, it's there! Update your Custom HTML content? Bam, it's there! As long as your users have a connection to the network, all the content of your app is available. And, in theory, if they don't have a connection to the network, than everything previously downloaded will have been cached and is available. A simply brilliant system! "But," you ask, "how can I make updates to my app that I don't want people to see quite yet? If it's online, won't they always see any changes I make?" Therein lies the rub. The simple answer is YES. If you have an online app, any changes you make get written to your Configuration Data file, and when the app checks to see if there are updates, there will be, and the new config file will get downloaded, including the changes you're not ready to roll out yet. There is a way around this, but it has a slight glitch to it. You can point your app to a configuration data file that exists somewhere like DropBox or your web server, and have that be the main file people get the app data from until you replace it with new content. However, there is a problem with that. When you go into your Control Panel and change the Configuration Data URL to point to this new location, you expect the app to grab all the content of the file at that location and serve it to your app. That indeed happens, but NOT UNTIL the app has processed the entire configuration file it's currently reading from. So, while your BT Server config file might point the user to a config file on DropBox, it will process the entire one on your BT Server, and then the one on DropBox. I tested this, and it's the way it works. That potentially exposes new content to users that you don't want them to see yet. I have not figured a way around this yet, so keep it in mind if you move your configuration data file expecting users to not see new content. They might still get it. Last thing to talk about is taking an online app and making it offline, so you can make changes and then push them out via a marketplace update. That's a great idea, but there is one flaw. The method here is to blank out the Data Configuration URL and Report to Cloud URL in your app. The next time people use the app, they will download the new config file, see that there is no longer a URL to grab updates from, and from that point forward, the app will be offline. However, keep in mind the caveat from above. The app will process the ENTIRE configuration data file, which means if you have made any changes to your app since you removed the configuration URL, those changes will be downloaded and visible to your users. That might not be something you want. Bottom line here is that once you decide to make your app online vs. offline, there is a huge problem in making big updates that you don't want to expose to your users quite yet. That problem is being looked at, but there is no solution coming in the very near future. OK, I think we're way, way past our five minutes here. I hope this helps in your consideration of online vs. offline apps. As usual, if you have any questions or comments, please feel free to post them, or contact me directly! Thanks, Mark [Edit - Made some changes based on feedback from @Fred. Thanks!]

a very detailed and great tutorial!

Another brilliant tutorial Master! Congratulations!!!

Thanks Mark, very well explained.

Glad people are enjoying it so far! Hope it helps your understanding of the subject!

Definitely, I hadn't read the online vs. offline apps document yet but your tutorial gave me the opportunity to read it in details. Now I think Buzztouch is even awesome-er! Farcat

"But," you ask, "how can I make updates to my app that I don't want people to see quite yet? If it's online, won't they always see any changes I make?" Therein lies the rub. The simple answer is YES. If you have an online app, any changes you make get written to your Configuration Data file, and when the app checks to see if there are updates, there will be, and the new config file will get downloaded, including the changes you're not ready to roll out yet. My solution would be: Have a password protected screen that contains new content until you're ready to roll it out. (Problem if you're making a lot of changes, because it'll cause app data updates. Or to make the changes but don't link new content to a screen until you're ready to roll it out. Fred

One problem I see with @Fred's solution is that what if you are doing a major revision to the app? This solution would be fine for content linked to current content (like new Menu List Items), but, if you were going to redesign, say, the whole menu structure of the app (like add menu list item icons, or change to a button menu), then that wouldn't work, because it would impact current users as you mess around with potential designs. I've given the online to offline thing a lot of thought and testing, and I simply cannot figure out a way to reliably hide changes from users. Once the app is out there, some people may choose to update on a regular basis, and other may never. For that reason, there is a lot of exposure in making huge design changes to an online app. Mark

Mark- Thank you. Excellent as usual! If I want to add AdMob to the code can I do that without submitting an update to Apple? (See, there's always one in every crowd!) Cheryl

Hi Cheryl, If it involves actually making modifications to the Objective C code (the .m and .h files), then you will have to recompile the app into a new version and submit an update. The only thing that doesn't have to go through Apple is when you make updates in your configuration file, and all the content (screens, media, etc) can be reached via the network (meaning you don't include it in the app itself). If you make changes where you want to include content in the app, or make changes to the underlying code...then a store update is necessary. Mark

Thanks Mark! And with that, I do believe was my final question :) Your advice has served me well, and I know many others too. Cheryl

Mark, perhaps you make a excellent argument for always initially having the Online Config file hosted other than the Control Panel since there will possibly be some one that does not update when you take an app offline. (There will be apps with various published versions at any given point in time.) This may not be critical depending on the nature of the app. If the app's local Config file initially points to say Dropbox, (App version #1) and you publish a second version pointing to the Control Panel (Version #2) (Easily done in Android) you can make all the changes to the app on the Control Panel and see the changes in version #2, which will not be reflected on version #1. When you're ready to update the Config file just copy the CP_Config file from the Control Panel to Dropbox. (Remember to re-modify the Config file to point to Dropbox.) Re-publish the app as necessary. Fred

Hey Fred, That's actually a scenario I hadn't considered, and one that makes a bit of sense! If you start with the app pointing off server, then you are always free to make changes and it won't impact users as long as you keep the remote config file updated. I think once you switch back to the server config file, though, you end up back where you started, but I can see how what you propose would work. I'll have to test and think about it for a bit. Mark

I meant to say copy the updated CP_Config file to Dropbox but continue to have it point to Dropbox. Fred

Good discussion, like the config file jiggery pokery.

Home run on this one Mark!

Thanks everybody! And it is a great discussion...it can be quite a complicated subject!

O and Fred also! Learning a lot from you two.

Great discussion, everyone! I have been creating entirely new projects in Buzztouch for major updates. If you don't have a lot of data, it really is very easy and seems the safest way to go. Someday we may be able to dupilcate a project, and then it would be even easier. That way you can stay online for minor updates and corrections with the old version and re-release to the App Store with a new version number. (I've only done this in iOS.)

Good suggestion, Susan. Thanks!

Great tutorial Mark. I found keeping the config data on my website is the best as the changes done in the control panel will not be pushed to users until I manually update the file on my site. Thanks for you effort again.

Thank you and please keep the info coming. Us newbies truly appreciate it

Mark... Seriously... Thank you... yet again...

thank god that GoNorthWest found buzztouch

Actually I think on day two David@Buzztouch created GoNorthWest. Fred

This would be a great topic for the buzz tour! I have read this a dozen times and I am starting to get it, but would love to have a demonstration of this.

Glad to hear that people are enjoying the tutorial! And I think it's a great topic for the buzztour as well! Somebody should suggest that on the forum. Mark

Excellent, just what I was looking for. I think for my own purposes I will try and ensure I have the right design when I start and then use Fred's suggestion for simple updates. Thanks for the hard work Mark, really is appreciated here.

After reading the update app suggestions I preformed a test. I have a new app that is not yet published to the iTunes App Store. I pointed the DATA URL to my webserver that contains the BT_Config.txt file. I then made a change to something in the control panel and the app still prompted that there was an UPDATE. I verified that the BT_Config.txt file in Xcode points to the new location and I also deleted and reinstalled the app on my phone before testing. Is it possible to host the BT_Config.txt file on your own server and make changes to the control panel for "App updates" and then update the BT_Config.txt on your own webserver when the updates are ready? In a perfect world you could point the data url to your webservers BT_Config.txt file. Then in the control panel point the date url back to "control panel" and download the source code again, so you can work on and see the updates on a device before pushing them live. Maybe I'm doing something wrong and this is in fact possible to do. If so PLEASE explain. I read Mark's tutorial and it was very good. I think mentioned something about the app "updating" issues when using a selfhosted BT_Config file. However, I wanted to see if anyone has had success doing what I am asking. Also, does the BT_Config.txt file have to remain BT_Config.txt when placing on a your own webserver or can I name it something else like "appName.txt"? Thanks for the advise and help. App in questions is created with v1.5 for iOS.

After reading the update app suggestions I preformed a test. I have a new app that is not yet published to the iTunes App Store. I pointed the DATA URL to my webserver that contains the BT_Config.txt file. I then made a change to something in the control panel and the app still prompted that there was an UPDATE. I verified that the BT_Config.txt file in Xcode points to the new location and I also deleted and reinstalled the app on my phone before testing. Is it possible to host the BT_Config.txt file on your own server and make changes to the control panel for "App updates" and then update the BT_Config.txt on your own webserver when the updates are ready? In a perfect world you could point the data url to your webservers BT_Config.txt file. Then in the control panel point the date url back to "control panel" and download the source code again, so you can work on and see the updates on a device before pushing them live. Maybe I'm doing something wrong and this is in fact possible to do. If so PLEASE explain. I read Mark's tutorial and it was very good. I think mentioned something about the app "updating" issues when using a selfhosted BT_Config file. However, I wanted to see if anyone has had success doing what I am asking. Also, does the BT_Config.txt file have to remain BT_Config.txt when placing on a your own webserver or can I name it something else like "appName.txt"? Thanks for the advise and help. App in questions is created with v1.5 for iOS. **** UPDATE **** After doing a little more testing I realized that when I make a change to the app in the control panel the "Do you want to update" message appears and if you click yes nothing actually updates until the BT_Config.txt file on the remote server is updated. It also appears that if the users have already said YES to update the app when you actually post the updated BT_Config.txt the user will NOT get prompted again until you make another change to the control panel. The constant prompting to users that there is an update and then nothing actually updates seems like a huge problem since making a lot of changes when working on a major update will cause users to see this prompts a LOT. Does anyone know away around this? Maybe remove "Report to Cloud" or will that put the app in offline mode even if there is a data URL attached? Is this what everyone else has experienced when posting the BT_Config.txt on your own server? *** As for renaming the BT_CONFIG.TXT this is what I found: I tried renaming the BT_Config.txt file to "appName.txt" and pointing the DATA URL to my hosted "appName.txt" file. This produced and error that went away once I renamed the file back to BT_Config.txt. Appearently it has to remain BT_Config.txt

Hi @Moto110, That's some good investigation there! We can write all the tutorials in the world, but it's practical experience that means so much more. This will be very valuable to everyone! Some thoughts I have: * If you leave the default ReportToCloud URL specified in your config file, then any changes you make in the control panel will cause the LastUpdated time to change, and when an app checks in, it will see things have changed since the last time, find the location of the Configuration Data, and download it. If the Configuration Data file is offsite, and hasn't been updated, it'll still pull it down, but obviously no content will update. * Keep in mind that your buzztouch app will process your entire BT_Config.txt file BEFORE it downloads any updates you might have at whatever Data URL you use. So, if you publish an app with the default URLs in place, and then later change it, a user will download any updates on the buzztouch servers before they go out and grab the new file. Does that make a bit of sense? * I didn't think that the file has to remain named BT_Config.txt, but it appears your experiment says it does! I'll have to check into that as well. Mark

I dont think it has to remain BT_Config. Whatever the error is will point to something that probably has BT_Config as a name that its searching for

***After doing a little more testing I realized that when I make a change to the app in the control panel the "Do you want to update" message appears and if you click yes nothing actually updates until the BT_Config.txt file on the remote server is updated. The two are separate parts. If the Config file is on a third party site (not Buzztouch) then any changes in the Control Panel will not be reflected in the app but the reportToClould URL will tell the app there is a change. ***It also appears that if the users have already said YES to update the app when you actually post the updated BT_Config.txt the user will NOT get prompted again until you make another change to the control panel. You can make multiple changes to a third party online Config file and the app will not update until you make a change in the Control Panel. ****The constant prompting to users that there is an update and then nothing actually updates seems like a huge problem since making a lot of changes when working on a major update will cause users to see this prompts a LOT. Does anyone know away around this? Maybe remove "Report to Cloud" or will that put the app in offline mode even if there is a data URL attached? Remove the reportToCloud URL and your app is offline until you bring it back online by publishing a new binary. What you're seeking to do is write a script for a third party reportToCloud URL that will report independently of the Control Panel. Then you could make changes without annoying the users. Short of writing a independent script, by having the online Config file on a third party site, you can take the app offline, make your changes to the app, then bring the app back online by publishing a new binary. User will only get two updates. One taking them offline. (From the third party online Config file.) Second taking them back online with the new content. Doesn't have to be to a third party Config file, but by using a third party Config file, you avoid the problem Mark lays out. By taking the app offline when modifying the app you avoid the constant notices to update. By returning the app online with the Config File on a third party site you can easily update the Config file. You just have to balance when to have the app online vs. Offline, but either way it's probably best to use a third party Online Config file. I don't see any benefit in renaming the BT_config.txt file. Fred

Hi Fred, Those are good, well thought out points. Not sure I completely agree with the "it's probably best to use a third party Online Config file" statement, because for new, less experienced users, it could cause some confusion and is potentially prone to mistakes. But, it's absolutely an option when you need to make changes to an active app. Key is, I think, to ship the first version of the app with the config file remote, instead of trying to do it after you've published the app. And I totally agree...no reason to rename the BT_Config.txt file. If a person needs keep track of multiple config files in this "DropBox" way, then they could always create a folder with the app name or something. It's best to stay with convention whenever possible. Mark

This is great information. After reading the suggestions I think I have now figured out how I plan to approach the issue. 1. Publish app with third party Online Config file. 2. If / When I plan to make MAJOR changes to the App I will remove the report to Cloud URL. This should then take the app offline for users, so they do NOT see any changes or get prompted that "data has changed" except for the first time to download the "EMPTY" report to Cloud URL. 3. Now that the App is "Offline" I will manually update the BT_Config.txt file within Xcode. This should allow me to see my changes in the control panel since the app is now offline. The other option might be to manually point the BT_Config.txt Data URL to the control panel in Xcode, but I think this would then download the "EMPTY" report to Cloud URL and take the app offline again. Any one have a better idea how to work on and see the major updates to your app easily while the Report to Cloud URL is "EMPTY"? **** Rename BT_Config thougths As for the reason to RENAME the BT_Config.txt. My thoughts were since the BT_Config.txt exposes your "APP ID AND API KEY" renaming the BT_Config.txt might help hide this information by disguise the file name. Maybe I'm just paranoid, but I wouldn't want someone to be able to Google Search BT_Config.txt and start finding these files sitting on webservers. Any thoughts or other suggestions on how to hide this file?

1. Publish app with third party Online Config file. 2. When you plan to make MAJOR changes to the App, remove the report to Cloud URL from the third party (not Buzztouch) online Config file. This should then take the app offline for users. They will receive one notice that the "data has changed" which will take then offline. 3. Now the App is "Offline". 4. Put the reportToCloud URL back into the BT_Config.txt file in your project side code. Now compile your app. A. For iOS: Sign this app with the Development certificate not the Distribution certificate. Your development app is now online. This will allow you to see any changes in the control panel since the development app is now online. The published app remains offline pointing to the third party online Config file. They will not see any modifications made in the Control Panel. B. For Android: create a new .apk. Upload the app to your device. You now have a online app that will display modifications to the app made in the Control Panel. When your finished with modifications (i) update the BT_Config.txt file in the source code. Copy and paste the source from the control panel. (ii) remove the reportToCloud URL (iii) publish a new binary using (the distribution profile for iOS) (iv) This will take user back online to the third party online Config file. Repeat as necessary. Fred **** Rename BT_Config thougths Question: How important is it to protect your "APP ID AND API KEY". Besides, the name of the file holding your third party online Config file does not need to be any thing in particular. Or does it? It's bring saved to localStorage, so it probably does need to have the same name. Fred

Fred - Very good info. Removing the Report to Cloud from the third party hosted BT_Config and NOT the control panel is the part I was missing in this puzzle. Makes perfect sense this points the users to the third party config and remove them from seeing the control panel changes or notification about changes. I am a little confused about how when working with the "new" source code after removing report to Cloud URL from third party config file and what cert you sign the app with make a difference as to whether or not you can see changes made in the control panel or not. Can you maybe explain a little more how this works? This is what you said. "For iOS: Sign this app with the Development certificate not the Distribution certificate. Your development app is now online. This will allow you to see any changes in the control panel since the development app is now online." As for how important is the "APP ID AND API KEY". I don't really know the answer to this I just know that Buzztouch documentation says this. "TREAT YOUR APP ID AND API KEY COMBINATION LIKE YOU WOULD A LOGIN / PASSWORD - KEEP IT PRIVATE" Seems important to protect it. However, I don't know what someone could do with it if they found it.

***I am a little confused about how when working with the "new" source code after removing report to Cloud URL from third party config file and what cert you sign the app with make a difference as to whether or not you can see changes made in the control panel or not. Can you maybe explain a little more how this works? ***This is what you said. ***"For iOS: Sign this app with the Development certificate not the Distribution certificate. Your development app is now online. This will allow you to see any changes in the control panel since the development app is now online." Essentially this creates two apps: The published app users find on the market it's either online or offline but points to third party online Config file. and The development app (it's online and points to Control Panel online Config file.) You could use separate source code files, but it's not necessary. Wouldn't recommend it since it adds another level of complexity (you must remember to make each an every change in both source code files. ) But having a separate source code file to play with does allow you greater leeway to experiment without worrying that you'll make a fatal mistake. Xcode has a backup feature, use it wisely. Dropbox also has a backup feature use it wisely. Fred ***As for how important is the "APP ID AND API KEY". I don't really know the answer to this I just know that Buzztouch documentation says this. ***"TREAT YOUR APP ID AND API KEY COMBINATION LIKE YOU WOULD A LOGIN /PASSWORD - KEEP IT PRIVATE" ***Seems important to protect it. However, I don't know what someone could do with it if they found it. Good info, missed the warning completely. Fred

Perhaps we need a method to make the third party online Config file accessible only by the app. A password protected file. Fred

Hi Moto110, If you look in your config file, you'll see this as the generic dataURL : http://www.buzztouch.com/appdata/v1.5.php?command=getAppData&appGuid=[buzztouchAppId]&apiKey=[buzztouchAPIKey] Thus, by knowing your aggGuid and apiKey, I can load up in my browser your entire configuration file, and see the inner workings of you app! How useful that is, I'm not entirely sure. It will expose any URLs that you have programmed into your app, which might expose the location of any back end scripts you might use in your app. It might also give hackers an indication of some entry points into your server, if you host some app content on it. But, if everything is located on buzztouch.com servers, then they'll not really learn much. A super smart, devious hacker could potentially (though I doubt it, because David @ buzztouch is super smart) hack the database at buzztouch and, using your apiKey, somehow mess with the other apps you've created, or perhaps your account in general? Perhaps there's some way to spoof being you with your apiKey? Overall, I'm thinking there's not a ton the average person could really use this info for. But, a very resourceful person might be able to find something. Not sure this entirely answers your question, but it's food for thought for all of us. Mark