I need to update some apps that are already published and I am realizing that I have a problem with Live/Design mode. I never changed anything so every app published is in design mode. I know how to fix that (I guess), but what I am still struggling with is how exactly do I update an app. I have been searching the forum for the last hour and have seen several references to documentation/tutorials on how to use Design/Live mode, but for the life of me I can't find this documentation. If there are any tutorials out there, I would definitely like to read them. I am struggling with how I can submit an update for review without changing all the apps that are already downloaded. It seems like if I hit the publish button to sync up Live & Design for review, it will change the apps that people have downloaded and they won't have the graphics or new plugins. If I don't hit publish the app to be reviewed will sync up with the old version and not show the reviewer what I changed. Am I missing something? Thanks for the help, Dave

Hi Dave, Ideally, when you publish your app to a store, you use the BT_Config.txt file that is in Live mode. That way, you can make updates in your control panel and test them out in simulators/devices where the config file is in Design mode, and people won't see the updates. As you have it now, if you've mode changes in your control panel, and all your users are running apps where the config file is in Design mode, they are getting ALL those changes pushed out to them. The purpose of the Publish button is to sync up the Live mode file with the Design mode file, thus "publishing" your changes to Live apps. Your first order of business should be to send an update to the store where the config file is in Live mode. That will set things back the way they should be, and allow you to do updates easier in the future. You can include graphics, media, etc, with the update. There are some instructions around on how to update your app in the store, but it generally amounts to recompiling your app with the version number increased. Everything else is pretty much the same. Hope this helps get you back on track. Post back if you're still stuck! Mark

I am working on updating everything so they are published as "Live". The thing I don't understand is when I should push "Publish" to sync up the Live & Design config files. Here is the scenario I am picturing. Version 1.0 has a button menu for the home screen. I have 6 main pages which each have a button with a unique graphic. It is published as "live". Version 1.1 is going to have a carousel menu. I am adding 2 pages so I will have 8 buttons on the carousel. Version 1.0 does not have the carousel menu plugin. I make all the changes, upload the new graphics and get everything working in design mode. I change "Design" to "Live" in the config file, compile, and submit to Apple for review. Here is the problem I see. If I hit "Publish" when I submit the revision to Apple for review to sync up the Design & Live config file, all the apps that are already out there will try to update and the app won't work because the carousel menu plugin and graphics aren't there. If I don't hit "Publish", won't the new version try to sync up with the old version of the app so the Apple reviewer will essentially be looking at the app as it already exists? I have not been able to see how this works first hand, but this is the problem that I see. Am I off base? Dave

I am working on updating everything so they are published as "Live". The thing I don't understand is when I should push "Publish" to sync up the Live & Design config files. Here is the scenario I am picturing. Version 1.0 has a button menu for the home screen. I have 6 main pages which each have a button with a unique graphic. It is published as "live". Version 1.1 is going to have a carousel menu. I am adding 2 pages so I will have 8 buttons on the carousel. Version 1.0 does not have the carousel menu plugin. I make all the changes, upload the new graphics and get everything working in design mode. I change "Design" to "Live" in the config file, compile, and submit to Apple for review. Here is the problem I see. If I hit "Publish" when I submit the revision to Apple for review to sync up the Design & Live config file, all the apps that are already out there will try to update and the app won't work because the carousel menu plugin and graphics aren't there. If I don't hit "Publish", won't the new version try to sync up with the old version of the app so the Apple reviewer will essentially be looking at the app as it already exists? I have not been able to see how this works first hand, but this is the problem that I see. Am I off base? Dave

In the initial design stages of the app, before it's published to a store for the first time, you would hit Publish as soon as you are done with the first version of the app. That makes the Design and Live versions of the configuration file the same. Then you would copy the Live version from your control panel into your BT_Config.txt file, and then upload to the store. At this point, your users would have an app that is in Live mode. Now, if you make changes to your app and test them at this point, you would do it with a version of the app in Design mode. All the changes you make in yoru control panel are first written to the Design mode version of the config file. When you are satisfied with the updates, you then hit the Publish button, and the files are again synced up. The, when a user opens the app next, they will be prompted for an update. The app will query BT, find that there is a new version of the file in Live mode, and push across the updates. That's the beauty of how Buzztouch works. If you are adding new graphics to your app, and want them to be part of the app vs. referenced via a URL, then you would need to publish an update to the store. You'd add the graphics to the app, hit Publish and copy/sync the configuration files, and publish the app to the store. There is one downside here, however. If you are adding new media, and you've hit the publish button, then people won't get the full update until they've actually gone to the store and received an update that way...the one that contains the new media. If they open the app before they've updated via the store, they'll receive an incomplete update, in that whatever is specified in the config file will be pushed across, but their version of the app won't have some of the media yet. Make sense? Unfortunately, there's no clear way around that, aside from referencing new media via URL instead of packaging with the app. Also...if you add a new plugin to your app, and you didn't have that plugin code when you last published the app, you'll have to provide an update to the store. And you'll need to hit Publish before you send the update to the store, which gives you the same problem I mentioned above. One last thing...hitting refresh in a forum post just reposts your last set of comments! ;-) Hope this helps a bit. Keep the questions coming if you have more! Mark

So it does sound like it works like I was afraid it does. I have some apps out there that have 10,000 + active users that I would like to upgrade to a Carousel Menu and New Quiz Module. Neither one of these plugins are loaded on the current app. The minute I hit publish, every app already downloaded essentially quits working. Given a multi-day gap between iTunes submission and review, I have an unacceptable downtime period where I will lose users and generate negative reviews. The one solution I can think of is to create an entirely new app and upload it. That will ultimately make my app console kinda confusing, but it is the only way I can think of to keep all apps working properly. The Live/Design option seems perfect for doing minor changes that don't even need to go through a review process. On the refresh button, I noticed that. Lesson learned. Dave

Hi Dave, Yep, the Live/Design mode is indeed most suited for updates through the control panel, and not major updates like the one you are in the process of doing. One thing you could do is make a copy of your current config file, and post it online somewhere (like DropBox or a web site). Then, in your control panel, change the "Configuration Data URL" in the Core Properties section to point to the URL for the config file. At that point, when somebody updates their app, it'll go out and start getting the data from that URL. Then, publish an update to your app and include the new Live configuration file and whatever other media you need. Make sure the Live config file points to the standard Live config file at Buzztouch. Then when a person updates the app, it'll update to the new config file, which then contains the new content! I think that'll work, but think it through a bit to double-check. Mark

Dave. Mark has explained the dilemma of the major update perfectly. What I have done to work through this is to send a push notification to all of my app users that there is a major update coming and if they notice any new menu items, screens, features, or overall changes that they should not access them until the app update comes through on their device. This strategy has worked well for me. Good luck. Brian