After reading this post (see below), I'm a little confused about how an app reads the Cloud URL and Data URL. Here is what I don't understand: Why does the simulator and my iPhone see the changes I make in the control panel when I have not used the default Buzztouch Cloud and Data URL? I'm not using any cloud or data url. http://www.buzztouch.com/forum/thread.php?tid=3E47613C78C66073A56E424&status=&searchInput=search...&sortColumn=FT.dateStampUTC&sortUpDown=DESC%C2%A4tPage=1&doViews=1

When you say you haven't used . . . do you mean you removed the links or you have left the default alone? If you have the default the the app checks for updates. Fred

Well, short answer is that it should not. If the data configuration file you have included in your app has the Report to Cloud and Data URLs removed, then it's considered offline, and should not ever pick up any changes made in your control panel. And that makes sense : If no Data URL is specified, then the only place it can look is at the internal configuration file. So, that makes me think that your local config file is not what you think it is. Have you verified that the local one...the one in Xcode or Buzztouch...actually does not have the two URLs configured? And, did you do a Product...Clean before you built to make sure any old links may have been removed? This, by the way, is not applicable for v1.4, which always must check a configuration data URL. Mark

This is what the control panel has: Cloud URL http://www.buzztouch.com/appdata/v1.5.php?command=reportToCloud&appGuid=[buzztouchAppId]&apiKey=[buzztouchAPIKey]&deviceId=[deviceId]&deviceLatitude=[deviceLatitude]&deviceLongitude=[deviceLongitude]&deviceModel=[deviceModel]&userId=[userId] Data URL http://www.buzztouch.com/appdata/v1.5.php?command=getAppData&appGuid=[buzztouchAppId]&apiKey=[buzztouchAPIKey] I've made no changes to those link and have not click on the "Use the default buzztouch URL". As well, I have made no changes in Xcode to any urls. Hope that info helps.

Yeah, you're still configured to grab the changes you make in your control panel. The v1.5.php script will grab all those variables you see in the string and fill them in based on your app, device, etc. If you hit the "Use default buzztouch URL," it would automatically fill in some of those for you. Basically same result. To take your app offline, you have to remove those links completely. As in noting but whitespace. But tread carefully, because if you do that for a published app, the only way to get the app back online is to submit an update to the store. Make sense? Mark

That makes sense. Ok so I want to submit my app as "online", so what happens if I do so without using the default buzztouch URLs? Will Apple reviewers run into issues view my app?

Well, recall that when you compile your app, you compile it with a local copy of BT_Config.txt. That file has to exist in order to even have the app work. So, here's the scenario: * You've finished creating your app on buzztouch.com, and you're ready to submit to Apple/Android * You want the app to be offline, so you blank out the Data URL and Report to URLs in your control panel * Now, hit "Show App's Configuration Data" in your control panel. This is the up to the minute version of your configuration file. Copy it all, and paste it into your local BT_Config.txt file * Do a Product...Clean, and then build the app as normal. The app is now offline, and will only use the local config file to feed the app its features In this scenario, when Apple tests the app, they will have everything they need, because the local configuration file is there. In fact, you could make changes to the app in your control panel, and they'd never know, because the app never checks. But, all the content you finalized on, it's there! Cool? Mark

Before submitting for review you should update the config file in your source code. Otherwise the old config file is what the reviewer will see. The mistake most people make is they think the cached config file is what the reviewer will see. The best practice is to clear the cache after packaging but prior to uploading to the app store so you can see what's being uploaded to the respective app store. Fred

@Mark, To further the config file discussion and understanding of the process I'm proposing the subsequent terminology: Local_Config file: The Config file found in the app (This file may vary from app to app, depending on the published version of the app.) SC_Config file: The Config file found in the Source Code. Online_Config file: Config file found online possibly Dropbox, Website, Buzztouch Control Panel, any other location that you point the Config file to. CP_Config file: The Config file as maintained in the respective Control Panel. Perhaps we need a name for a text edited Config file prior to it's insertion into the source code. Part of the confusion is due to the lack of understanding the various permutation of the Config file. If we use said terminology I believe it'll be easier to explain to users what's happening and for user to ask questions because they'll have to differentiate as to which config file they reference. Fred

Hey Fred, Good point. There are quite a few permutations that can be had with the config file. I like your suggestions...I'll try and use them going forward. Mark

Mark and Fred, thank you so much for the feedback. This is awesome info. Mark, I think there was a little misunderstanding when you provided a scenario. It was based on the app being offline. What I was wondering is what happens in this scenario: 1. You build the app in Buzztouch wanting it to be an online app 2. You forget to use the default Buzztouch URLs and you don't "blank" them out 3. You download the package, update the config file in Xcode as Fred mentioned 4. Submit to Apple for review

CP_C_Config file : A Config file created via the Control Panel (In explaining the Config file in question, one would say, "the Local_Config file is a CP_C_Config file". Perhaps for new users it would be best to spell it out. But having the terminology you can create the concept for the users.) UC_Config file : A Config file created with a text editors. UM_CP_Config file : A CP_C_Config file that's been modified. Fred

1. You build the app in Buzztouch wanting it to be an online app When you download the source code the SC_Config file and the CP_Config file are identical until you make additional changes via the Control Panel. 2. You forget to use the default Buzztouch URLs and you don't "blank" them out. The the Default settings are by definition there. You don't have to remember to use it, it's there. 3. You download the package, update the config file in Xcode. When you update the Config file the SC_Config file is again identical to the CP_Config file. 4. Submit to Apple for review As long as you don't make any changes via the Control Panel everything will look great. The problem comes up when the app is packaged with a config file that represents an incomplete app. Fred

Mark Hi! What do you mean by doing a "Product...Clean?" Blue

Hi @chrisasleson, My bad...misunderstood the scenario! Fred is exactly correct, but I'll summarize so it's doubly explained. * If you don't touch the Data URL and Report to URL at all...leaving them exactly as they always were...there app is considered online, and it will check for updates on the buzztouch.com server (or your own BT Server) whenever the app is opened or brought to the front * You only need to download the package once...the first time you request it. After that, the only thing that changes is the configuration file * In order to make sure Apple sees your app as you intend it...meaning, as it looks when you considered it "finished" and were ready to submit to iTunes, you should copy the buzztouch.com version of the config file and put it in your local config file. That way they will be in sync. Then build the app and submit. When the reviewer opens the app, it will check for updates, see that the file is the same as the one on the server (assuming you made NO changes AT ALL), and will NOT prompt for a refresh. Make sense? @Fred...I'll try and get used to the new terms...I promise! Mark

@Blue, In Xcode, you can from the top menu bar select "Product", then "Clean." That will break any links that Xcode built in all your code, and build them all again. It's a good idea to do that from time to time to make sure it's built as fresh as possible. There is a similar option, also called Clean, in Eclipse, but I can't recall from memory. A very simple explanation, but does it make sense? It's just a step you should do from time to time. Check out this doc...I think I have a screen shot there: http://www.buzztouch.com/resources/Submitting_Your_App_To_iTunes_Connect_v1.0.pdf Mark

Fred and Mark you guys totally rock! Super helpful and I like the new terms Fred has created. Makes it more clear to a noob like me. If I could just bug you both one more time (hopefully lol) that would be awesome. Say all the instructions are followed that both of you have laid out but you make a change in the control panel before Apple has a chance to review. Apple rejects your app because it's not working. Should you just deleted download package from company, follow all instructions again and provide Apple with a new binary. Also, if you don't need to check the "use default urls" because it will work the same anyway, they why even have the option? Thanks so much guys!!!!

Apple will not necessarily reject the app. It depends on what the app looked like at the point the local_Config file was packaged. If the app was fully functional with a fully functional SC_Config file then the app will have a fully functional local_Config file then it would probably be approved in the review process. What usually happens is that the SC_Config file was never updated and it's JSON data would give you a unfinished app. When you update the app's data the CP_Config file is downloaded and cached and the app is fully functional but that's because the app is using the Cached_Config (new term) file and not the local_Config file. But some one downloading the app would only have the local_Config file until they update the app's data. Hence, Apple will reject because the app is unfinished. Fred

Thanks! I believe I followed all the instructions laid out when submitting but when the Apple reviewer opens the app they just get a white screen. I'm gonna have to go back to the drawing board to see if I missed something or why it is that the app isn't working for them.

Yep, Fred's got it correct. My advice is NEVER touch your app after you have submitted it, before it gets approved. Doing so, even to tweak the slightest thing, will cause the time stamp on your CP_Config file to change, which will initiate a refresh. That, I would think, is a negative impression for the reviewer. The lesson here is test, test, and test again before you publish your app. Make sure your config files are in sync, and that the app works as you would like in the simulator and device. Then publish, and make it hands off until it's approved! With respect to the default URL question, notice the difference between what's there without you touching it, and what's there if you hit "Use Default URLs." Lots more info gets passed to buzztouch if you just leave it alone, and that URL shows you all the sort of information you can collect and send from the app. If all you want to do is send info to initiate a refresh of the config file, without all the extra stuff like deviceID and Location info, then using the default URL is the way to go. Keep the questions coming! Mark

If you want to send me your project files, I can open it in my Xcode and see what might be up. MrkFleming at gmail dot com. Mark

Should you just deleted download package from company, follow all instructions again and provide Apple with a new binary. You should probably submit a new binary, but it would be nice to hear from someone that's been in that situation and how they proceeded. Also, if you don't need to check the "use default urls" because it will work the same anyway, they why even have the option? You don't have to check anything. It's the default. Fred

Would having the app on your phone and opening it to show people what you've created effect the CP_Config file? Could that be why Apple can't preview my app?

No, your phone can't modify the CP_Config file. Fred

If you're able to get the same results running it in the simulator, the reason for the problem is very likely shown in the debug console. Mark

Simulator and my iPhone run it just fine. I don't see any problems in the debug console. I'm sure I could be missing something I guess. Anyway I'm positive I followed all the steps but I'm just going to delete all the files on my computer and start from scratch.

Sounds like a plan! Hopefully it works out. Can't wait to see what you've come up with! Mark