We have been using HockeyApp for Alpha and Beta distribution and crash reporting. We are planning to submit the app to AppStore. We have created a new slot on HockeyApp with same bundle id as the AppStore build. And included the app ids and keys of the slot in the AppStore build.
Question is, do we have to upload the ipa that we submit to itunnesconnect to the HockeyApp slot as well for crash reporting or crash reports will be captured even if no ipa exits in the HockeyApp Slot?
For crash reports, it is generally not necessary to upload the .ipa file. To get proper crash reports, the only thing you need to upload are the dSYM files of the exact same build that will be shipped to your customers through the store.
These dSYM files are used to "translate" the gibberish memory address from the raw crash report back to readable method names, file names, and line numbers in a process called "symbolication".
Please be especially aware of the difficulty that enabling Bitcode adds around symbolication: https://support.hockeyapp.net/kb/client-integration-ios-mac-os-x-tvos/how-to-solve-symbolication-problems#bitcode
Related
So I did what many suggested and kept TestFlight SDK in the release build to be prepared when FlightPath finally launches.
However: After following TestFlight's instructions for the predecessor called "TestFlight Live", TestFlight refuses to accept my App Store IPA (continue reading) and gives this message:
Invalid IPA: The keychain-access-group in the embedded.mobileprovision
and your binary don't match.
I did what they said:
1) Made a release build and submitted to the App Store, with TestFlight SDK and checkpoint calls included, but -setDeviceIdentifier: call removed.
2) From Xcode Organizer window: Selected the submitted archive, clicked "Distribute" to re-structure it as a TestFlight-compatible binary, signed for AdHoc distribution over TestFlight.
Apparently this binary is garbage for TestFlight which lefts me wondering: How am I supposed to ever get to the analytics data once FlightPath arrives? Am I better off rejecting my submission and stripping out all the useless TestFlight SDK code or can this be fixed?
You don't have to upload the app store build of your app for it to work with flight path. As long as you have uploaded or created an app that has the same bundle id and app token the app will appear in flightpath without you having to upload.
Make sure you have the correct app token that matches your bundle id!
I just compile the IPJSUA and build using xCode 4.3.2, and also run on simulator. But still can't call/send IM.
I'm thinking about limitation for simulator, now I want to deploy into .IPA file and test it using my phone. But I got an error.
If I'm using iPhone Developer Certificate, I got a lot of error like this pic.
If I'm using iPhone Distribution Certificates, I got a error message like this.
No unexpired provisioning profiles found that contain any of the keychain's signing certificates
Anybody ever try how to make IPJSUA into .IPA files?
What different between iPhone Developer Certificate and iPhone Distribution Certificate?
Here is the picture, I already linked the library, the architectures, and the search path.
I already can make the .IPA file, but still can't make a call or send IM. can you make a call with IPJSUA using your devices/simulator?
thanks.
UPDATE: Already can call/send IM/add buddy. I will Refer to the new question that I will answer by myself. The step by step of using PJSIP on xCode. Thanks.
If you're just testing it on your own phone, and your phone is registered in the developer portal then there is no need to generate a .IPA file. You can just plug your device into the computer and build it directly onto the device. If however you want to distribute to multiple devices that aren't registered yet(such as friend's devices), i would suggest looking into testflight which simplifies this process, and gives a step by step instruction here on how to create and upload your IPA.
It took me days to get ipjsua running on devices. A couple things I ran into:
Are you linking to all the proper binaries? There's about 20 or so you need to link to, you can check their ipjsua sample app for reference.
Did you add the armv7 and armv6 architectures in your build settings? We had to add both (this was probably back in September of last year when we were building it, for reference)
Are your Library Search Paths and Header Search Paths in build settings correct? For headers we have pjsip/include, pjlib/include, pjlib-util/include, pjnath/include, and pjmedia/include. For Library paths we have all the same (with /lib instead of /include of course)
Unfortunately i have a problem with distributing my app. I have almost finished project, that is tested by me, and then I'd started beta-testing. Testers sent me reports about bugs, that I wasn't able to repeat. For example, app calculates finances of user (simple summing of data). And some times app adds some great numbers to result, that isn't right.
I found that this bug appear only on distributed version. It mens that compiler differs for debug and distribution?
While debugging I tested my app on simulator and different devices, different iOS simply compiling project on target or making .ipa file form .app file.
Version for distribution I made with ad-Hoc provision, using build and archive on distribution configuration, and than using share for archive.
What's wrong? Why could appear any new bugs after distribution and how can I avoid it?
I send a new version of my iPad app to AppStore. The Apple will now validate it.
But, I want to have absolute certainty that NOTHING gone wrong. I have the Archived file and want to run it.
Ok, I can build a new program and run it in the device. But I want to test the exact file that I sent.
I tried to create a .ipa file but it give-me problem with "code signed". Run the file in simulator is a good idea. So, there are a easy way to run my new version?
You cannot install on our own device an app you build and is signed with your distribution certificate. Put another way, the build you submit to Apple cannot be directly installed by you on your device.
If you build any other way such that you can install that build on your device, it's the same code as you would otherwise be sending to Apple in a distribution build.
I have had the same desire, actually. I have an app with a conditional build setting based on whether it's a distribution build or not. For a distribution build, we have a production API URL, but for all other builds the URL is a development sandbox URL. So, I know how you feel! I wanted to be able to test the actual build sent to Apple to make sure it was hitting the correct production URL. I couldn't. I had to trust. :-)
I'll assume you're using Xcode 4; details will be different if you're using Xcode 3.
Once you've created an application archive, you can select the archive in the Organizer and click the Share... button to e-mail it to yourself and/or your testers. Xcode will let you sign it with your developer key, so you can install it on your device. When you're satisfied with the app, you can then validate and submit the app to the app store, again from the Organizer window. You'll re-sign the app with your distribution key and the application will be uploaded to iTunesConnect.
Just make sure your project and your target Build settings are absolutely 100% identical between your final Release build and your Distribution build, except for code-signing. Then do a clean build of both, one after the other, and QA the final Release build before submitting the Distribution archive.
After Apple approves the app, delete the app from one of your devices, and buy your app from the App store. That's the only way to get an exact customer download with the full customer experience. You'll get back 70% of the purchase price in a couple months; the other 30% is likely a very small part of your total development and testing cost.
I found this previous question about Cocoa projects, but I wanted to know if it's the same for iPhone projects.
As far as I know, the same responses there apply to iPhone development as well. In my projects, the only files I keep under SVN's control are the source files, any resources (images, .XIBs, audio, etc.), and the .xcodeproj file.
It may be a good idea to version control provisioning profiles. Especially for an ad-hoc beta test profile, you'll need to update it every time you add a new beta tester, and having a history of that seems like a good idea.
Actually there is something I would say you should version control that you would normally not - the final application bundle and dsym file, both under build. However, you only need to archive these when you release either an ad-hoc or distribution build for the store - so I'd leave build in the ignore file, but have somewhere you can copy these files to check them in for a distribution and tag them along with the source.
You'll probably want to compress the app bundle before placing it in this save directory
You need these two files in order to be able to symbolicate crash logs sent to you by either beta testers, or users of the app from the app store. A meaningful stack trace of a crash is priceless!
If you're planning on updating the app over time in addition to project sources and media you may also want to put the following under version control:
Signing certificates for app (and/or mobileprovision files).
The final version of the binary app (zipped) submitted to Appstore.
Binary.dSYM file for each revision (for post-release crash symbolicating).
Screenshots/icons/text file of description for app as submitted to Appstore.
Before beta releases you may also want to put mobileprovision files as well as a snapshot of the device list from the Developer portal for that version just so you can go back in time and figure out who got what release. If you're really hardcore you can also keep emails submitted by beta testers so you can keep it all in one place and go back and double-check against bug reports.
Yes. I use the exact same .gitignore file for iPhone OS projects as I do for Mac OS projects.