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.
Related
We have submitted an update version of our existing applications in the App Store recently. But we have received a issue from one of the users, saying that the app is not functioning properly after the update. So in order to replicate the same, what are the steps to reproduce, so that i can analyse the issue?
Any help will be appreciated.
To simulate this before pushing yoru updated version to the AppStore you can:
Download the old version of your app from the appstore
Run the updated version of your app from XCode on the same device.
What will happen behind the scenes is that your app will be updated in a way similar to the Appstore. Your app will be partially updated while your doucments folder will stay the same. (what usually causes problems)
This solution is better because it lets you check for problems before and update was pushed to the Appstore.
Yeah, I get this a lot. The solution is a bit annoying, but you need to keep a history of IPAs you've submitted so you can put the on your phone through iTunes (so not the simulator) and then, run your code on your device putting a breakpoint on your applicationDidFinishLaunching handler in your app delegate, and start tracing from there. You should be able to find the old app store version in your organiser from the last time you submitted, or, go through your SVN/GIT history and checkout the version tagged to your release version.
Many times in the past that has happened to me where I test a new revision and everything looks fine but when I submit an update and is approved, users start complaining about a crash or lost data.
This is way I approach the problem.
(This is most important step) You need to either have your old code or old binary installed on your actual apple device. (Physical iPhone / iPad)
Now go to iTunes and install your new update.
Attach your physical iPhone / iPad to you computer, Launch Xcode and start debugging it.
NOTE: There have been many times when things work perfectly in the Simulator but break on the actual device. Its always important to test your code on the real thing as that is what the users are going to be on.
All that is required is to have the version of the app that is in the app store on your device, then install the updated version to your device. You can debug it using Xcode when you install the new version.
Some days back i had few problems regarding the version updates from iOS 4.0 to 6.0 . The entire database was cleaned when the new version was installed .
Is there any way I can test version update before submitting to apple ?
I tested version updates via
Hockey
AdHoc build installed via iPhone configuration utility.
Is there any other way i can test the things so i can be sure that the update will not have any problems?
You can test it via TestFlight service. It's a great tool and I use it often to test my updates.
On a fresh phone (or a phone that does not have your app on it), download the current version of the app from the App Store. Setup all the necessary data, create values in your database, etc. Then update your app in the phone via adhoc release or TestFlight. The key point is to have the most up-to-date public version of your app first.
Try out Crashlytics. It provides instant and detailed crash reports, right down the line # at which a problem occurred.
It negligible in size (a few hundred KB), but even works on release distributions! That means even if you miss a few bugs, you will be notified instantly the moment a crash occurs, rather than having to wait for the useless Apple Crash Reports to be published.
Hope that helps you out a bit.
I realize this is a stretch and I can't give much info to help but I am reaching for anything. My App has been under continuous development for 3 years and never seen anything like this. I recently submitted a small point release to Apple for Release, and twice now it has been rejected for Crashing on Launch on ALL their devices?
The Crash reports point to some code in static library but the key lines are not getting symbolicated. Tried Atos no luck.
The key point is that I have 7 devices I have tested the app on in every mode I can think of, in particular no connection to anything: Wifi-OFF, AirplaneMode-ON, Location services-OFF. I can NEVER simulate what they claim to be seeing, which is App crashes on launch every time?!
I found one report in the AAPL Dev Forums that sounded similar, but he never got any explanation as to what was up. After he submitted an app with loads of logging in it out of desperation and asked them to send the logs. They got that version and... approved it in hours.
Anyone have ANY ideas. I NEED to get this release out.
NOTE: Resolved
This turned out to NOT be a weak link issue. We only saw the crash when running the App using Ad Hoc distribution of the Archive version as Brad suggested... so that was helpful.
However the resolution turned out to be some compiler flags which I listed here:
https://stackoverflow.com/a/10302012/754494
I'll repost and expand upon my comment from above so that this question can have an accepted answer.
I recently came across a case similar to this when building my GPUImage framework. It appears that the build process is slightly different when archiving than when building and directly installing an application on the device via Xcode.
This can be exposed by building and archiving the application, then choosing to distribute it for ad hoc or enterprise distribution. Take the .ipa and place it in iTunes and manually load it on one of your test devices that way. The behavior of an application prepared in this manner may differ from one built and installed through Xcode, and should be closer to how a build submitted for review will act.
In my case, the problem was due to a lack of proper weak linking. On SDKs newer than iOS 4.3, you should no longer need to weak link whole frameworks if you wish to conditionally use classes and functions that are present in newer SDKs but missing in older ones. If you target 4.0 and higher, the linker should now perform class- and function-level weak linking.
However, this was failing for people using my static library, which does runtime checks for the presence of the new texture cache functions in iOS 5.0, but it only failed in these archived builds. I never saw it in all my testing against 4.x devices, because that was done by installing via Xcode. In the end, I needed to have users explicitly weak link the entire Core Video framework in order to get applications using this framework to run properly when archived and installed via iTunes.
Note that this wasn't due to the Release vs. Debug build configurations, because I tried switching between these in my build schemes when deploying to the device through Xcode and it made no difference there. Something else is different in the way that archived applications are built and linked.
I recently recovered from not being able to test on my device in Xcode. After much headache, it turned out that I only needed to uninstall/reinstall iTunes, but I'd certainly rather not do so frequently.
(See: prior thread)
The troubles seemed to begin after I built and ran some sample projects which obviously did not have my App id, etc. Is this always the case? Should I live in fear of compiling other projects that I haven't previously associated with my device and/or developer profile?
I'm not exactly sure if the App id/bundle/provisioning/keychain/whatever needs to be done per test ad hoc App or if it only matters that your device is provisioned and your plist matches what Apple has when you go to upload to the iTunes store.
I've run many samples on my device through Xcode and never had any issues. There's certainly no reason why this should happen.
It's hard to say "No, you shouldn't be worried" without knowing what the issue is, but it's not intended to break in this way, and it doesn't for most of us!
I really combed this site and others. I read and re-read the related links here and the Apple docs. I'm sorry, but either I am obviously missing something right under my nose, or this Apple profile/certificate stuff is a bit convoluted. Here it is:
I have a product in the App Store.
I have updated it several times and users like it.
My development profile recently expired just when I was improving the app for its next release.
I can run the app in the simulator.
I can compile and put the distribution build on my iPhone just fine.
I went to the Apple portal and renewed the development profile.
I downloaded it and installed it in Xcode.
I see it in the Organize window.
I see it on my iPhone.
I CANNOT put the debug build on my iPhone to debug or run with Instruments. The message is that either there is not a valid signed profile or it is untrusted.
I subsequently tried to download and install the certificate to my Mac's keychain.
Still no success.
I checked the code signing section of Project settings and also for the target and the root. All appears to indicate that it is using the expected development profile for debug.
Yes, I had deleted the old profile from my iPhone, from the Organizer. I cleaned the Xcode cache and all targets. I have done all of this several times and in varying sequences to try to cover every possibility.
I am ready to do anything to be able to debug with Instruments in order to check for leaks or high memory usage. Even though the distribution compile runs fine on my iPhone and plays well with other running processes, I will not release anything without a leaks/memory test.
Any ideas will be appreciated. If I missed something obvious, please forgive me - it was not due to just posting a question without searching for similar postings.
Thanks!
All problems solved! I am very happy this all happened because I learned so much about Xcode, keychains, certs and provisioning. Unfortunately, there is not a simple answer. Here are the highlights:
I needed to recreate the ad-hoc profile and install it on my device. (That was MY BIG oversight and the reason the dist build no longer ran on my device.)
Between the very first time I created my profiles and the date my development profile expired, I upgraded to the 3.1.3 Xcode SDK.
It seems that this now means you need 2 entitlements files; a debug version with the get-task-allow checked and a distribution version with get-task-allow unchecked. Each need to be set in the respective settings.
In Project settings, I needed to set both my working directory and intermediate directory to the build product directory.
BIGGIE - I had to double click on the target and reset the appropriate code signing profile. There was an old profile name still there for some reason! Now, I can debug, and drop my distribution on my device without a hitch.
So, in summary, I believe that my original problem (not being able to debug after renewing my dev profile) and the problem that resulted from all my efforts to fix the first were caused by:
the fact that I upgraded to 3.1.3 during my dev cycle
my own oversight (I apologize to Apple for my criticism)
an Xcode quirk (the old profile name hanging around in target settings).
I hope this helps others. The best advise I can give is to take a day off and then create a new empty project, going through the same process step by step.
Thank you all!!
Try re-creating your development mobileprovision file on Apple's site. Be sure to delete all old copies from Organizer (including those on the iPhone itself).