Hello David, I know you are really busy, and I'll try to be brief, but after much trial and error, I can't seem to solve an upgrade issue with my iOS app in the app store. Here's what happened, Version 1.0 (based on v1.5 of Buzztouch) of my app has been in the store for several months. I decided to switch to BT server and post an update to my app, naming it version 1.1. Basically, the app has been completely redesigned with BT server 2.0 I thoroughly tested the app and Apple approved the update to the app store. First time installs of version 1.1 of my app, based on BT server 2 work just fine. The issue comes for folks who are updating/upgrading from version 1.0 to 1.1. after the update procedure, when the user opens the app, it is appears to be a broken version of 1.0. So the new update using the BT server codebase is not overwriting my old v1.5 codebase. In order for existing v1.0 users to use my new update v1.1, they need to remove v1.0 completely and reinstall. I have been researching the issue and it appears as if the device's app data store - <application_home>/Documents/ folder is not being cleared out, thus creating a conflict with the older, cached files. I am trying to prepare an update/fix that detects the presence of the old cache files in <application_home>/Documents/ and <application_home>/Library/ and remove them. Thus treating the app as a new install, rather than trying to merge code from the previous versions cache. I have been using iOS developer library tech note TN2285 for insight into how to do a +deleteCacheWithName: during the update process. http://developer.apple.com/library/ios/#technotes/tn2285/_index.html Anyways, I figured I would throw this out there to see if you have encountered this before and/or if anyone else encounters a similar issue. I created a post yesterday in the forums regarding this issue, but I didn't know what I was looking for at that time, so it is not very concise. http://www.buzztouch.com/forum/thread.php?tid=60F5C9E9F662BEC0551E17C Thanks in advance for any insight, and thank you for everything you and the Buzztouch team are doing! Best Regards, Brian-

Hey Brian, When you get this sorted, please post a tutorial. I'm sure there are quite a few of us that will be experiencing the same issues. Good luck! Thanks. Jeff

Hey Jeff, Thanks! Yeah, I needed to pick up the red phone on this one after spending hours trying on my own. Kind of been a nightmare, folks who update my app get a nuked version, with old corrupted data from the previous version. I thought that when you download an update from the app store, the new binary overwrites the old one. Much to my surprise, this is not the case. Old code gets compared to the new code. I understand that for certain apps, application state has to be preserved between upgrades, user settings, personalization etc... I think I am getting close, especially with a pot of coffee flowing through my veins :)

Looking into this now....sit tight for :30 or so for some info.... @MGoBlue: Expect an email later this evening (after researching this topic) later about the Android questions we discussed the other day.

Following conversation...

OK, this is is NOT something I've dealt with or heard. I understand a few posts have been made about the issue but I didn't see / respond to them. It makes perfect sense that this could happen. I was 100% in my understanding of how the app update process worked. I've been operating under the assumption that ALL data (cached data and program data) was overwritten during app updates. The idea that it is not is very important and for sure we need to consider this in the future. @birwin needs to consider it now! Yikes. It's a relatively easy process to remove all the cached data. The built in iOS method (deleteCacheWithName) could be used, passing nil as the file name to remove all the cached data...or...a built in buzztouch method in the BT_fileManager class could be used to do the same thing. I'm used to the buzztouch method. However, simply adding a line of code to remove all the cached data isn't a good approach unless some basic logic is coded to make sure it's not deleted every time the app launches. The cached data should only be deleted the first time the app launches after the update. The solution... I'll post the code here and the forum will for sure ruin it so I'll also make a .pdf and add it to the how-to's after finishing this post. a) Check for the existence of a dummy file in the cache. b) If the file does NOT exist in the cache we must be launching the app for the first time (after an update or the first time ever). In this case, delete all data. c) Save the dummy file to the cache. In subsequent launches, the cached dummy file will exist and the 'delete all cached data' routine will not run. We'll use two built in BT methods in the BT_fileManager class to perform the operations so we don't have to write a ton of code.. The code (with forums hijacked quotes!). Past this directly under the -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions... line. This means this code will run before any other code as soon as the app launches: //create a temporary dummy file name NSString *dummyFileName = @update_01.txt; //if this file exists, we have already done this process, continue without doing anything... if([BT_fileManager doesLocalFileExist:dummyFileName]){ //because this file exists, do not do anything, we have already done it... }else{ //we must be doing an app updated or installing for first time, delete all cached data... [BT_fileManager deleteAllLocalData]; } // save dummy data so this is ignored next time... [BT_fileManager saveTextFileToCacheWithEncoding:@dummy data:dummyFileName:-1]; This should clear up the issue. I'll post a PDF with better code shortly.

Hello David, I can't thank you enough for taking a look! I have been trying to piece together a solution with deleteCacheWithName, as referenced in the iOS tech notes. Using your method would make more sense, and be safer. Next time you are in the Vacaville area, I need to buy you lunch! When you post the PDF, I'll try to test it out in an update scenario and report back. Thanks again! Best Regards, Brian-

Vacaville: Damn, just drove through today on way to Sac-town. Back your way late next week, remind me to google a starbucks! PDF Is much easier to read: http://www.buzztouch.com/resources/cached-data-after-updates.pdf

Don't wish to hijack this post, so please create a new post as is appropriate. My question has/will android users face this problem?

LOL! That's too funny! I could have held up a sign! I'll keep in touch about Starbucks! Thanks again for your help! Best Regards, Brian-

@David. Are you in Sac? We should grab coffee tomorrow.

Hi @David, Your PDF says, for step #2, if the dummy files DOES exist in the cache, then it's an update. I believe you mean DOES NOT exist. Mark

@GoNorthwest: Yup, typo, fixed. @MGoBlue: Was in downtown Sac all morning, back to Monterey already. Crazy project with some city-folks, up-n-back drive. Coffee next week for sure. Sounds like I'll be in Vacaville at starbucks meeting @birwin on the way up(?), Rancho or Folsom in afternoon maybe? Could be Wed or Thurs or Fri..dunno yet but for sure one of those days. @Fred @ mySkylla.com: Good question. This URL explains how it works a bit.. http://developer.android.com/guide/topics/data/data-storage.html#filesInternal Looks like we'll need to dig into this and test the behavior. Haven't been able to find any definite answer in the android docs so some tests are in order.

@David. Sounds great. Just shoot me an email when you know your schedule.

Hey David, I have been testing this solution. It appears as if the dummy file gets wiped out at each launch of the app. The app tries to refresh at each launch as well. It appears as if the update_01.txt gets wiped out at each load, and so does everything else? Here is a snippet from the Xcode log: BT_fileManager: File does exist in cached directory: appModified.txt BT_fileManager: readTextFileFromCacheWithEncoding: appModified.txt encoding: -1 mytestapp_appDelegate: previousModified (value on device): Wed, 18 Jan 2012 10:00:56 -0700 BT_fileManager: saveTextFileToCacheWithEncoding: appModified.txt encodingFlag: -1 BT_networkState: Monitoring Connection: WiFi Not Available BT_screen_splash: animating splash screen BT_fileManager: saveTextFileToCacheWithEncoding: cachedAppConfig.txt encodingFlag: -1 mytestapp_appDelegate: downloadFileCompleted mytestapp_appDelegate: hideProgress BT_fileManager: saveTextFileToCacheWithEncoding: cachedAppConfig.txt encodingFlag: -1 BT_application: validateApplicationData BT_application: The application data appears to be valid. BT_fileManager: deleteAllLocalData BT_fileManager: deleting: Parse BT_fileManager: deleting: appModified.txt BT_fileManager: deleting: update_01.txt I'll keep testing and see if it is something in my configuration. I also connected a test device and used iExplorer to navigate to the cache directory in the app itself, and update_01.txt is not in there.

Ah, yes, my hasty fix didn't consider the fact that we are calling deleteAllLocalData later on in the code. Yikes. This means we are saving the file when the app first launches, then remove it a few milli-seconds later. Duh. I'll get the PDF updated. In the meantime, just change the place where we are creating the file. Remove this line you created earlier... [BT_fileManager saveTextFileToCacheWithEncoding:@dummy data:dummyFileName:-1]; and we'll save it AFTER calling the deleteAllLocalData in the code in the downloadedFileCompleted method. Look for deleteAllLocalData call on or around line 640 and add this just UNDER the deleteAllData call: //save the dummy file so we don't do it again the next time this app launches.... NSString *dummyFileName = @update_01.txt; [BT_fileManager saveTextFileToCacheWithEncoding:@dummy data:dummyFileName:-1]; that should do it.

Interesting, I have parse push notifications enabled on my app, and I had to move the block of code and place it above launchOptions, Like this - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)newDeviceToken { // Tell Parse about the device token. [PFPush storeDeviceToken:newDeviceToken]; // Subscribe to the global broadcast channel. [PFPush subscribeToChannelInBackground:@]; //create a temporary dummy file name NSString *dummyFileName = @update_01.txt; //if this file exists, we have already done this process, continue without doing anything... if([BT_fileManager doesLocalFileExist:dummyFileName]){ //because this file exists, do not do anything, we have already done it... }else{ //we must be doing an app updated, delete all cached data... [BT_fileManager deleteAllLocalData]; } //save the dummy file so we don't delete the cache the next time this app launches.... [BT_fileManager saveTextFileToCacheWithEncoding:@dummydata:dummyFileName:-1]; } -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

Thanks! I'll move my experimental code out of parse push notification area back to where it should be

That did the trick, dummy file is in the cache! Thanks again David!

subscribing. just about to go thru this process today.....

Hello @ATRAIN53, This trick seemed to work for me during my update, however you may want to run a test before sending it in to the appstore. They call it an upgrade/update scenario. You delete the version you have on your test phone now. After that, you create an ad-hoc distribution build of your old version (the version you are using now), Then use iTunes to drag the app into your test device, then run a sync. After it is successfully installed on your test device, make sure it opens etc.. Then create another ad-hoc distribution build, this time with your new version/update, drag this build onto your test device and sync using iTunes, by doing this, it will simulate an upgrade procedure. As long as your bundle identifier is the same as your first version, it should work. If you open up your new version, hopefully it will open and not be blank. This link has a full explanation of the process: http://stackoverflow.com/questions/2524326/how-to-test-an-iphone-application-update Look towards the middle of the page for a step-by-step rundown. Best Regards, Brian-

@birwin/Brian thanks for the tip, i will give that a try next week. theres also another thread here i'm following with another tip for dong updates- http://www.buzztouch.com/forum/thread.php?tid=E8FC60B766B8E6913C5D79C&status=&searchInput=Update&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=2&doViews=1 i'll probably try both methoids and see which one i like better. right now i need to finish the android version of my app and get that up in the store. it's insane how this whole app project went from an 'experement' to 'we have to have this out in the field -- NOW!!!' in just a matter of a few weeks once the company saw the potential. that's good/bad because i'm not 100% confident in all aspects of BT technology yet. i wanted to move it to my own BT server before i deployed it but no time to resolve those issues...

I'm a bit confused about this post. The current pdf contains the following: //create a temporary dummy file name NSString *dummyFileName = @update_01.txt; //if this file exists, we have already done this process, continue without doing anything... if([BT_fileManager doesLocalFileExist:dummyFileName]){ //because this file exists, do not do anything, we have already done it... }else{ //we must be doing an app updated or installing for first time, delete all cached data... [BT_fileManager deleteAllLocalData]; } // save dummy data so this is ignored next time... [BT_fileManager saveTextFileToCacheWithEncoding:@dummy data:dummyFileName:-1]; however it should be as such now? In BT .m file 2.0 around line: 640 .. //delete previously cached data (this does not remove the config file we just created) [BT_fileManager deleteAllLocalData]; Add the following code: NSString *dummyFileName = @update_01.txt; [BT_fileManager saveTextFileToCacheWithEncoding:@dummy data:dummyFileName:-1]; correct?? Thanks!

Has this ever been resolved? I'm having the same trouble with an app update going from 1.5 to 2.0. Many users are reporting only a tab bar with a blank screen. Deleting and reinstalling fixes the issue and fresh installs work fine. I don't think I can delete the whole folder because I'm using the Notepad Plugin and that would delete all of a user's notes. I also have an issue with an update to an offline 1.5 app that is using old config data. Again, deleting and reinstalling fixes the issue, and a new install is fine. I'm getting scared to put out updates now. Could be related to the directory change from NSCachesDirectory to NSDocumentDirectory? All I need is for my offline apps to use the bundled config file and not an old version!

I'm now getting errors when I go to build the App. I've included a picture below. http://imgur.com/t8ExJr0

Can Anyone help? When I add the code I get errors in Xcode. http://imgur.com/t8ExJr0