I've gotten a couple of bug reports from customers that I am unable to duplicate with my devices. These aren't crashes hence no crash reports. I'm trying to figure out what options I have to solve these bugs. Keep in mind that these customers vary widely in their technological prowess and willingness to help out.
The best I can think of is making an ad-hoc build with logging enabled to a file in their documents directory, but then I need a way to get that file off their phone.
Specifically, Short of remote debugging (that would be great) I want to get a log file or some other diagnostics to see what is going on.
What options do I have?
EDIT: Great information already given, but I am looking for something like 'writing log statements to a remote server', probably just for an ad-hoc (for debugging) build. So, basically, by looking at their log, hopefully, I can deduce where things go wrong. I could build such a system, but wondering what is already out there.
Once you have the ad-hoc build, you can send the app to your customers, so that they can install it in iTunes and from there on to their iPhones.
Dragging/dropping on iTunes your app will place it in the App folder.
As to retrieving your log file, you could implement copying of your log file back to itunes (like many apps do), so the customer could get it from there and send it back to you... or you could simply post the file through HTTP to a server of yours under the customer's control.
AdHoc + TestFlightApp.com - extremely easy, powerful.
Flurry is an option.
Related
I have place several NSLog() in my iOS application, is it possible to see all the logs later on my Mac that was generated when the app ran on iPhone handset even when iPhone was not connected with Mac.
Thanks
No. You can however redirect NSLog to a file, using something like this: http://blog.coriolis.ch/2009/01/09/redirect-nslog-to-a-file-on-the-iphone/
Then you can access the file via Xcode, or upload it with your app. File usage and privacy issues apply.
Keep in mind that NSLog is supposed to be turned off in published apps, so you may want to use a different logging app. A number of NSLog alternatives are available.
Unfortunately this is not possible.
The only thing that you can get is a Crash Log.
If you need a better logging system, I suggest to take a look to CocoaLumberjack, a very powerful logging framework that gives you the opportunity to save log in files and, eventually, send them to a server.
You also have many different levels like: log info, log error, log warning, etc...
You can view crash logs from your iPhone in the Organizer.
If you want to view your own log statements, you could consider TestFlight ( http://testflightapp.com ). They offer an SDK which includes features for remote logging.
I'm fairly certain that's not possible. The device needs to be connected to the Mac in order to run in Xcode's debug mode, and you need to be in debug mode to view the console, which contains your NSLogs.
There is a crash log for every crash that occurs on the phone, which is readable after connecting to your mac. These NSLog's don't appear in this log nor do they appear anywhere else in a (semi) permanent manner.
It's possible using custom macros and a custom class which will write each message in the documents directory in a file.
If the file sharing is enabled in the app you can later download them in iTunes.
Seeing the logs in mac might not be possible. But you can send the log to testflight using TFLog(). But you will need to distribute your app through testflightapp. And integrate the sdk. I think that is what you are looking for. try out - testflightapp.com
The crash log returned when your app has an error on iOS is wonderful however it would be 100 times better if it contained the console output from when your app started as part of the log. Is there a way to automatically have that information in the crash log, or have a semi-automatic system that testers could use when sending in crash logs?
I think you might want to take a look at http://apphance.com. It's exactly what you are looking for - including capability of sending problem reports from device by testers, including screenshots, you can track history of session including full console logs, you can even see crashes from out-of-memory problems which are otherwise difficult to get without physical access to the device. It's closed beta for now but soon it will be open for everyone. You can request access directly at the page.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the service.
#Medran i am not sure if this will help but if you can get the Brad Larsons videos on Advance iPhone App Development than there he says some thing about .dSYM file that will help you find the places where crash occurs. .dSYM file is made when you build your app using Xcode. See if you can find that file in your project folder its named something like this MYapp.app.dSYM
We are currently developing an app for a client in the US, we are based in the UK. We need to "proof" the app as we make changes with our client i.e. get them to check the updates before we go any further.
The issue we're having is that transferring an IPA file to our client has been advised by their legal team as illegal. Is there any other way (simply) to allow our client to view this app regularly as we update it?
Cheers
IANAL, however, their legal team is wrong. When I click Build and Archive, and then Share by Email, the generated email file contains an ipa. This is an Apple-sanctioned method of doing ad-hoc sharing of iPhone apps.
What is probably confusing them is that if you're pirating apps, you use ipa files as well. However, saying that sharing ipa files is illegal is like saying sharing .exe files is illegal. Sometimes, yes. In this case: no, so long as the devices that are running it have been properly provisioned.
Grepping around, I see that I'm not AT ALL alone in being... challenged... by the process of setting up an iPhone app, getting it to run, giving it my testers, and so on.
I've gotten it to work. Somehow I emailed a copy or two to testers, and eventually got my li'l app into the store, and that was fine.
But I can't say a really, deeply understand it! (And I don't do iOS dev every day. Even now my recollection of what I did is kind-of hazy.)
I'm moderately capable of understanding things, if presented, well, you know, in a way I can understand.
Can anyone point me to a crystal clear explanation of what provisioning actually is?
I feel that if I understood it, the recipes to do it would be obvious.
Thanks!
Development provisioning profiles sign your application, and allow the phone to know it's OK to run. These days, XCode automatically makes a Development Profile for you (the "Team Profile").
The other kind of profile, when you are talking about other people running you app, is a Distribution Profile. You need a Distribution profile for either giving your app to the store, or for giving to beta-testers.
The profile is what allows other people's phones to know it's OK to run your app, basically it includes a list of device ID's approved to run that application on the phone in question, along with being signed so that the phone knows the whole thing is valid.
If you read advice around the web concerning distribution, it's easy to get confused because things used to be a lot harder. You used to have to send Distribution certificates separately from your app to beta testers. These days the certificates are included in your app bundle so you don't have to worry about that.
Furthermore, sending an AdHoc build can be all kinds of unpleasant - for testers using Windows. These days, the absolute best way to do beta testing is have a link on the web that uses the Enterprise ad-hoc deployment feature, to let a user with iOS4 or higher automatically download and install your application with no iTunes or copying work at all. In fact I would at this point refuse to use beta testers running windows who were not on iOS4 or higher.
The guide link posted should have a section about the enterprise ad-hoc, but basically the way it works is there's a small plist file the phone downloads, that has a link to the IPA file containing your app. You point the phone to a specially formatted link to the plist file and the phone fetches the application directly.
All of this is predicated on using the "Build and Archive" option for building any ad-hoc distribution build. You should do that anyway because it also saves out a symbol file for you to use in debugging crash reports.
EDIT:
Here's a little more detail on enterprise deployment (which works for any registered developer, not just Enterprise registered developers):
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
The Developer Program User Guide should be helpful.
If my company is a member of the Enterprise program where we can distribute apps internally for any number of users is there a good way to handle app updates? Everything I see on installing such apps is saying I have to send the .app and a profile to the end users for them to add to iTunes and then sync their device to install. Is there any way to have the user's computer or device know when I have an update to the app available or do I just have to redistribute the app file manually again and hope for everyone to update manually?
Although you can update configuration profiles over-the-air, it doesn’t appear that you can do this. Your best bet would be to implement a notification in your app when it starts to tell the users to upgrade. See the Enterprise Deployment Guide [PDF].
It might be a little late to answer this, but I'm facing the exact same problem.
After spending some time looking for a solution we've come to the conclusion that this can be done in two ways:
You can achieve a lot of things with a Mobile Device Management (MDM) server. You can force installation of applications, and perhaps this can work if you want to update. You can collect information on what version the app is running, and then perhaps directly target users with outdated versions of the app: http://images.apple.com/iphone/business/docs/iOS_MDM.pdf I don't have access to an MDM, so I haven't tried this out.
Finally, build in some kind of deprecation functionality that tells the user to update. This is what apple recommends ( http://help.apple.com/iosdeployment-apps/#app43ad802c ) (and the solution we are going for).