I have an application already on the store and would like to release an update. Since my app deals with databases and I've had to change some parts of it, I would like to ensure that the update does not affect the existing functionality in any way once the user updates from the App Store.
What I did was this - install the first version of my app on my device. Changed the update's version in info.plist to 1.1 and run it via xcode (and install on my device). But what happens by doing this is some of the changes I made to the XIBs do not show up. It looks as if the app was only half-updated (if you know what I mean)
Is there any way to update an existing app programmatically without having to go through the app store and then find out it could lead to a disaster?!
Thanks for any help!
I would double check your build configuration. Between building the two versions of the app, I would recommend a "Clean All" just to be safe. The process you described works to verify updates. The only other alternative I can come up with is to create Ad-hoc distributions of both versions of your app, and install those.
Related
How can we make the flutter app to make automatic update whenever we release a new version of the app into the store. but I don't want to use the pop up to alert the user to update I want to update automatically without letting the user even know we update it.
As said in the comment, if you publish to Google Playstore or iOs AppStore, they will handle the updates for you. You just have to upload the new version (just set the release number correctly) and, when the validation is done, their system will notify/update the app. I don't know how other stores behave, but I'm guessing that's the standard behaviour now.
Instead, if you need to bypass the store functionality and perform the update "by yourself", I don't think that is gonna be a simple task. Apple simply doesn't allow installation from other sources than their store, so I fear it may be simply impossible. On Android, on the other hand, I know that's possible, but it will require some user interaction beforehand, since the "installation from unknown source" authorization must be provided to the app that downloads/opens your .apk file, and the procedure may vary from a device to another, so I fear there won't be a single mechanism that will work everywhere.
In any case, the base mechanism will probably require some HTTP GET by your app towards some webserver that will reply with the latest version: the app should then compare the received version number with its own, and then proceed to the download of the package (the URL for the download can be provided along with the latest version number). After that, you have to manage somehow to install/update the downloaded file.
I personally used this approach with Flutter on Windows 7 and newer, where there are no store constraints and I can simply run and download the .msi or .exe file for the latest version, and works just fine.
I think you are looking for the concept of codepush which was loved by many React Native developers.
In Flutter, I think you might want to check out flutter_code_push if this fits your needs.
I have been working on an iOS app update and am ready to submit it, however I am having a small issue I am concerned about. I create an ad-Hoc version for testing and when I try to synch the update over to my phone via iTunes it won't give me the 'update' option next to the app. The buttons in iTunes says 'remove'. iTunes actually forces me to first remove the old version of the app and only after it is removed, iTunes gives me the option to install the new version and then the app works fine. The only problem is that this is not really testing the update process and I am concerned that once I release the app to the app store my users will have the same issue where they will not be able to just update the app, they will have to remove the old app first and then install the new version. Any idea what might be going wrong here?
iOS takes care of updating Apps, as far as bundle identifier in your info-plist is the same, any newer version will show as an update in iOS. But in iTunes things work differently. You don't have to worry about these things.
If you want to test effects of updating an App, Install the old version from AppStore. Connect your device and Run the project from Xcode. Now this will work the same way as updating your app.
There is no problem from your part. Maybe this time iTunes is not smart enough to know that your ad-hoc version is an update one or maybe the version of the app on iTunes and on your phone is the same. I've made a lot of update to my apps, when you submit a new one to AppStore your user won't face this problem. They will find an update button for your app :).
today my app update it has been released in the store, when updated or downloaded for the first time the app immediately crash on start.
I've tested the app on simulator and on device (the same where I've installed the update from the store) and I never experienced this problem.
My update it has been submitted with Organizer after the archiving, in the Distribute section.
Apple do not perform these types of controls before to release an app?
Anyone experienced a similar problem? I have no idea what could be the cause..
Thank you, Stefano.
Here's the best way to test a production build without deploying to the store:
Set your build Scheme to "iOS Device"
Do an Archive build
Select your archive and click Distribute
Choose "Save for Enterprise or Ad-Hoc Deployment"
Pick your code signing cert
After saving the ipa file, use Apple's iPhone Configuration Utility(*) to install it on your device
You should always perform two tests:
installing on a blank device after uninstalling your app *and any profiles in Settings -> General -> Profiles"
installing over the top of the previous version of your app, to make sure any files/preferences/etc are properly converted to the new format
(*) the iPhone Configuration Utility is mostly used for enterprise app deployment, but it's also useful for developers and is available as a free download for mac and windows at support.apple.com. You can also use iTunes instead, but it's convoluted.
As for why your app is crashing? No idea... it could be anything. Standard debugging advice applies.
The issue is related to the Framework. I had this exact error. It wasn't a case of logic as it was crashing before the AppDelegate was even called and my usage of NSMetadataQuery was much later in the life cycle than that.
It turns out that weak linking the Foundation framework was required.
Problem was solved by changing (under the Project Info in Xcode) the dependency option of the Foundation.framework from required to optional. Check for any such frameworks.
Try deleting any old versions of the app you have on your device, and reinstall. Also try on a different device, maybe with a different apple id to your developer account.
This happened to our app also, and apparently, other apps too.
Apple is aware of the problem and is currently working on a solution.
see this article:
http://techcrunch.com/2012/07/05/apple-responds-to-app-crashing-issues-has-a-dedicated-team-working-on-a-fix/
If you are using core data & you have updated database in your latest version without versioning core data in that case app crashes on launch after update.
Is there a way to simulate the update of an app from Version 1 to 2?
I am not sure about what happens when I build & run an application in Xcode. I believe that when the app is already installed in the simulator, an update is happening just like it does when the user downloads a new version from the App Store. For example sqlite3 database files remain intact when I hit Bild & Run, while the binary of the app itself gets replaced.
So the question is: Is THIS already a safe way of testing update procedures? What are the alternatives PRIOR to releasing the app and getting dozens of bad reviews?
Unless you change a saved file, it remains as it was. If you really want to test this, then just install the current/old version on a test device. Then build the new version onto the same device. This has the same effect as an update through iTunes for the users.
If you have a separate test team that doesn't have access to the xcode project, they can still test updates using the xcode organizer:
Install the old version of the app on your device and use it a bit to simulate real user behaviour
Install your provisioning profile on the device
Open the xcode organizer and drag the new copy of your app onto the device
That'll keep the existing data intact, allowing you to test the new app with data from the old version.
I have an app on the Store for which we’re readying an update.
The other members of our team have the App Store version already loaded up (~purchased) on their respective iPhones -- and those contain User Data which each member needs to be able to keep.
In the meantime, we need to test out a Beta version of the next version of the app.
Presumably, we’d need to have the two versions (ad hoc, and app store) co-existing on each device, at least until everyone’s signed off on the beta and it’s uploaded to the store (at which point, they'd delete the beta version).
[Once it’s on the Store, of course, they can each update their main (i.e., Release) version of the app via the usual App Store 'update' mechanism. In that case, all their user data is still retained intact.]
So assuming that’s the proper workflow ...
How do I issue a Beta to the team, and have it not replace/overwrite the existing App Store version?
I’ve tried customizing parameters in the beta’s “[appname]-Info.plist”, but haven’t found a setting yet that allows the two versions (beta and release) to co-exist on the same device.
Any ideas? And is this is the proper approach to them being able to keep their data?
(And last, how might I do it with & without a script? I assume there's just one parameter that'd need to be changed.)
I hope this all makes sense -- thank you in advance for your help!
So you want to have two versions of the same application on one device? I don't think there's a way to get this effect -- updating an application, which keys on unique CFBundleIdentifier, replaces old version bundle but not data.
For the effect you want, you must have two distinct applications. They need different CFBundleIdentifiers, so they won't overwrite each other. They then cannot share data, so you'll have to arrange for export/import involving an off-device shared space.
If you don't want this hassle, issue the team extra devices and test on those. The team's primary devices remain on the AppStore version. You must still export/import to bring content from the test devices to the primary devices. Any paid content each has on the App Store version should be available for their beta, though, as usual for app upgrades and one-owner multiple-devices scenarios.