I already have an iPhone application (version 1.0) available in the App Store and am ready to submit a newer version (version 1.1). How do I test the new upgrade to make sure that the current sqlite database and property list files on the earlier version do not get deleted/overwritten etc? The new version assumes the old data in both the sqlite database and property lists remain.
Or better yet, is there a resource I can use to walk me through what to watch for when developing an application update?
The way we tackled this when we wanted to test our database upgrade code was to use ad hoc distribution.
We had our testers download the 1.0 app from iTunes and install it on their test devices.
Then we built an Ad Hoc distribution of the app using a configuration based on the Release config, and made sure that it had the same bundle identifier. As long as the bundle identifier is the same, the new app should overwrite the previous version.
We asked our testers to install the ad hoc build as they normally would, by dragging it into itunes and then syncing the device to simulate upgrading.
As far as I know, this is identical to the user downloading and installing an upgrade via the app store on the device itself.
As you'd expect, the documents folder should be left intact, leaving your database in place, and your app should be able to run its upgrade code to modify the database in the way you need.
Hope this helps :)
Test like so:
delete app from device.
install v1.0 app (or .ipa file) into iTunes
sync to device, iTunes will install the app
launch app on device, create and save data, etc.
quit app on device
install v1.1 app (or .ipa file) into iTunes; iTunes will ask to confirm replacing older version of the app.
sync to device, iTunes will update the app
launch app on device
test using existing data with new version of the app.
Related
I built an app, and I'm distributing it for testing OTA. It is targeted for iOS 5.0 and above and is configured to be universal (so should work on both phones and tablets). It has been running just fine on both kinds of devices. Today I put out a new version. It installs just fine on tablets. However it won't install on phones running any version of the os from 5.0 up. They just get the message 'This app cannot be downloaded.' All of these users are verified provisioned. I'm not sure what I could have done between versions to keep this app from being installed on phones now. What should I be looking for as a possible issue?
It runs fine in the iPhone simulator
If you have access to any of the iPhones the app won't install on, you can connect it to xcode and view the device logs for why the installation failed.
That'll give you the most definitive answer.
If you can't access the iPhones, I would say you should regenerate your IPA file and make sure the target you're building the IPA for has the right configs (universal app, iOS version, provisioning profile assignments etc.)
Not sure why this helped, but I decided to export the ipa with a new file name this time. I didn't modify any settings in the package anywhere other than giving the .ipa file a new name. Doing that fixed it. Now everyone can download it again.
I'm testing a Trigger.IO app built with Forge v1.4 on an iPod running iOS 6. I've been installing the .ipa through a distribution provision profile.
Occasionally, after installing an updated version, the app would launch but not run correctly. I traced this behaviour to the window.forge being absent, presumably due to a bad initialization. I would then make sure to kill the app process before installing updates and my recollection is that this seemed to make the problem go away.
Now, I've added the Facebook and Splash modules and my app now consistently won't go past the splash screen after I install an upgraded version unless I forcibly uninstall the old version first. Presumably, it dies before creating the webview. Any idea why I would need to uninstall my app first before upgrading? Is this a known behaviour?
I want to make sure that my users don't experience this when upgrading.
My app runs happily without Forge, and doesn't have any particular dependencies on localStorage data. I don't have a Mac and have been installing via iTunes in Windows, so I don't think I can access logging information.
You should have a look at this post:
How application get update from apple store?
The quick answer is when you update an app, you install the new bundle but you keep the user data stored previously such as a local DB. If you changed the local DB in the new app (or anything else) your app can crash when updated but is fine when downloaded from scratch.
I am trying to simulate an upgrade from version 2.0 to 2.1. I have version 2.0 hosted in testflight, so I did install it in my device. Then I tried running the app from xcode. However what happened is that the app did not get overlapped, instead it created two apps with the same name. How can I make it such that when I run the app from xcode it overlays the old version?
I've made sure that the bundle identifier is the same.
Well the info you can get while updating can be found # this link here.
when user updates an app, Documents folder is stored as is, including
NSUserDefaults (but, sometimes user download app via iTunes and
replace the whole application, crying 'OMG! update killed all my
levels progress!'); Application bundle is erased and replaced by new
one (anyway, it is readonly for user); Re-deployment of new build
version will be enough;
You can't access the appstore inside the simulator because: # link here
It's a simulator not an emulator. Even if there was an App Store in
the Simulator, none of the apps in the store would work since they are
compiled for ARM CPUs while the Simulator runs x86 code.
Another stack overflow # link here states:
Build and install your old version, generate some data, and then
install the new version on top of it.
For testing before submitting to the Appstore I generally download
from the AppStore again the old version, and then install with Xcode
the newer version - for your next update... ;-)
And another stack overflow (that I lost the link for) states:
No, the simulator runs i386 binaries and iPhone appstore apps are ARM
binaries apps.
iOS apps are compiled to machine code, Android apps are run in a
Virtual Machine using byte code and are translated to machine code at
the time they are run.
So no, I don't believe you can run it in the simulator, how ever you can have older projects saved on the iPhone and test both out. And the apple documentation is # this link here.
Read this: https://developer.apple.com/library/ios/technotes/tn2285/_index.html
You cannot simulate update in XCode (neither in simulator or connected device). You have to create IPA file and simulate update process via iTunes.
I am working on an iPhone application for a customer. After the development will be finished the application will be on the Apple Store, but meanwhile during its development, on a regular basis the customer wants to see and install the application on his own phone to check the current status of the development.
-I went to the provisioning portal registered my customer's device udid and added to my application's provisioning profile.
-I downloaded the provisioning profile and installed it.
-I then built the ipa and sent it to my customer.
SHouldn't this be enough?
The customer is experimenting a sync error. He can import the ipa inside itunes but at the end of the sync he receive this error alert on his iphone.I tested this ipa file on two other iphones and is working (both registered and one is ios 5.1 and the other 5.0.1)..Where should I check for misconfigurations?
I'm running the latest xcode version 4.3.1
Make sure you build with the distribution provision. I use a new Xcode build configuration for this (called Ad Hoc) and I make sure my archive build uses this new build configuration. The customer will need a copy of this distribution provision (which he double clicks), and you send him the ipa file. He drags this into his iTunes library and he is then able to install the app to his device.
Sometimes the provisioning profile needs to be installed on the device separately. I encountered this problem once with my team member who had Windows.
Just send your customer the profile and ask to install it on the device.
You may need iPhone Configuration Utility to install the profile on the device.
I have an iPhone App which is available on App Store.
Now I have made some changes in my existing App which can be tested only when an App is available on App Store.
So I want to release newer version but I want to test it first before it it available on App Store for all users
And once it is tested and if it works fine as per expectation then only I want to make it available for other user.
How can I do that?
The short answer is: NO - there is no way to make an app available on the app store that only you can download and test.
If you can specify exactly what it is that you are trying to test that only works when the app is live, we may be able to suggest a different approach.
EDIT: if you just want to test the upgrade process, you can just install the new version on top of the old one - there's no need to delete the one already on the phone. For example if you download the version from the app store, run it, and then build and install a version from Xcode, it will install on top of the app store version, and keep all the settings and documents from that version, just like if a user was upgrading.
Also read up on "wireless distribution" for adhoc apps. Using wireless distribution, you can download and install the app from a link on your phone, just as if you were doing it from the app store, except the link will only work for UDIDs that were included in the adhoc profile.
Two choices:
OTA AdHoc Distribution
Set up over-the-air Ad Hoc distribution. These guys can help: https://testflightapp.com/
A user can install an adhoc build over an appstore build without deleting data, and vice-versa.
Side-by-side Builds
Ok, so your question is about side-by-side installation: you want a user to have the real app and a test version on the phone at the same time. To do that you just need to create version of the app with a different bundle Id. So if your app is com.myco.MyApp, create a copy of it as com.myco.testing.MyApp. Then use Ad Hoc distribution (or whatever) to get it to testers.
I've got a build script that updates the bundle version with the build number. I'm actually just about to update the script so that it will modify the bundle Id so I can have side-by-side testing. This is what I do for the bundle version on my build server:
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion '${PROJECTBUNDLEVERSION}'" $PROJECT/Info.plist
Presumably can do something similar for the CFBundleID:
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier '${PROJECTTESTBUNDLEID}'" $PROJECT/Info.plist