I have an issue when running my project on my device, but only if it has been downloaded from testFlight. It works fine when I build directly from Xcode to device.
Potentially relevant details -
Using AVCaptureSession, my app records segments of video where it can switch between front/rear camera etc. I have handled orientation of each video so when playing back or merging with multiple videos they all play the correct way round.
The playback orientation works as expected on my devices when I've built directly from Xcode. Though from the app dowloaded from Testflight, the orientation of the videos are wrong way round.
Devices used iPhone 5S - 8.1 & iPad 2 7.1
As mentioned, this is only an issue from TestFlight builds. I've not posted any code as logic works fine from Xcode. I have used TestFlight a lot over the past year and not come across an issue like this before. It only seems isolated to this video playback.
If anyone has had similar issues and knows how to resolve or has suggestion, that would be much appreciated.
I discovered why my testFlight build was acting different from my Xcode build and it all came down to Build Configuration settings within Xcode
I edited scheme which which brought up build options and within the Run option I changed Build Configuration from Debug to Release.
Although this never solved the video issue, it did allow the app to act as it would on release. I will now be able to continue test of my issue, but thought other people experiencing differences in their Xcode and test builds may wish to know about this setting.
Do you happen to be using Swift. Apple changed their certs and added an extra field as part of the process. Existing certs do not work when including external libraries that include Swift code. I lost a good chunk of time to this. Here is the explanation form TestFlight competitor AirSign.
https://www.airsignapp.com/ios-apps-using-swift-crash-when-signed-with-inhouse-certificate/
If this is the case, the conclusion is generate a new cert and a new provisioning profile using the cert. You may have to revoke your old cert if you have too many.
If you build directly from your machine you are using your development Cert. If you go through TestFlight you are using you distribution cert. What happens if you take the distribution ipa that you are about to upload to TestFlight and try to install that directly onto you device. IF you can not install the app then there is an issue with your distribution cert. I also assume you tried building a new hello world type app and going through TestFlight and then adding AVCaptureSession in a new build of the app and trying that.
To make my life easier I use iFunBox to directly install test ipas directly on my machine bypassing iTunes. Great free app. Just launch, Choose Install on Device and choose the ipa
http://www.i-funbox.com/ifunboxmac/
Related
How I can link my ipa binary with calabash, for test in xamarin test cloud without build from xcode? I currently try with the optool from command line, but not work.
It is possible to link a prebuilt IPA with Calabash using Xamarin Test Recorder, however there are several limitations you should be aware of:
IPAs must be provided from the developer. Apps from the app store are encrypted in a way that Test Recorder is unable to interact with.
Test Recorder requires a valid development provisioning profile and signing identity that can sign the app locally. This is because when Test Recorder attempts to inject Calabash into the IPA it must be able to resign the app on the local system.
Test Recorder requires a iOS device you can deploy to based on the provisioning profile. This is almost an addendum to my last point, but it distinct because you will need a physical iOS device present for Test Recorder to record on; and it has to be included in the provisioning profile because that's an Apple requirement to install & run an app on a physical device.
Test Recorder is still in preview. As such, bugs & issues may be more common compared to working with the rest of the Test Cloud toolchain. Fixes may also be slower in being pushed out compared to the rest of the tools. However, you can still report Test Recorder issues to the Test Cloud support team for investigation by going to https://testcloud.xamarin.com and clicking on the "Support" link at the top right hand side of the window.
Note: This answer is tweaked from the answer I wrote to a very similar question in the Xamarin Forums here: https://forums.xamarin.com/discussion/100461/do-i-need-the-source-code-to-execute-xamarin-test-recorder#latest
More info on Xamarin Test Recorder: https://www.xamarin.com/test-cloud/recorder
I am trying to figure out why my apps file size is so large when I install a beta build with Fabric Beta (created by Twitter).
When archiving the build and checking the app size I see that it is about 194MB, however, when I build and install the app for debugging on device, the storage space that is taken up is ~85MB.
When I install the app via Fabric Beta, the app is ~194MB on device.
Would anyone be able to explain what is going on here. Is there an issue with Fabric that is not optimizing the build?
Old question, but worth clarifying I think real quick:
1 comment said:
Most likely the ipa for uploading has arm6 and arm7 binaries in it. As long as you have bitcode turned on then App thinning will only push down the parts that an individual device needs.
And this is true, and then this follow up comment from original question author
I see. And is there any way to confirm this for a client? Because Fabric has been the only platform we have been using. Will I see the correct file size with iTunes Test Flight?
The answer to that is yes. Test flight, since basically the closest you can get to the App Store without actually getting reviewed (although TestFlight requires Beta App Review, but this is usually pretty quick.
TestFlight should handle the proper app thinning and send you only the app binary sized for your device.
I have an iOS App with Testflight's sdk 1.1 enabled to get production data. This worked well during beta testing and I submitted the same build (with sdk enabled) to Appstore and the build is approved and released.
However, I dont see any data regarding the usage in testflight live. I have been looking around to find if there are any special setup needed for that without success.
Note that I DONT have the same build version as in appstore in testflight anymore. But I figured that testflight live will still be able to show usage dat.
Anyone have experience with this? Can someone point me in the right direction
After checking around, it looks like as of v1.1, you NEED to have the same build that is submitted to Appstore to be in testflight as well. The reason is that the event matching is done using the UUID of the build.
Their support indicated that they are working on handling orphaned build events as well.
Hello all!
I want to test how my Cordova-ported apps run on real device, and if I like performance, I'll buy Apple Developer Certificate. But now I dont want to waste hundred bucks just to see my webapps running slow and ugly as shit. I've looked through all that forums and also here on stackoverflow, and all solutions seem to relate to iOS SDK 4.2 and earlier.
And what about Xcode 4.3+?
I've edited /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/SDKSettings.plist and also turned out code signing in project settings.
I've got two MyProject.app's from "Build for Running" and "Build for Archiving" and tried to sync them to my iPod touch 4 via iTunes, but in both cases app crashes immediately after launch.
I also extracted .ipa from iTunes and tried to install it via Installous, but got the same problem. Thing crashes.
I also got .xcarchive via Product->Archive but don't know what is to be done next with it..
So, question is here: how can I deploy my own app to my own jailbroken iPod touch?
Thank you.
I would suggest you to take a look at JailCoder.
It allows you to Debug your app made with XCode on a real device without a developer account.
Please keep in mind such solution should only be temporary. If it runs well and you want to do further developing / deployment consider buying a Developer account.
On jailbroken iDevices, Cydia (and other dpkg installers) install apps to /private/Applications/
So why not try:
/Applications/MyProject.app
Then open a terminal on the device and navigate to /Applications:
chmod -777 MyProject.app
chown root MyProject.app
I have an iOS app written by someone else that I need to put on a colleague's iPad. We recently got an Apple Enterprise developer account, so in-house distribution becomes available, and is in fact the preferred distribution method in this case.
I was able to switch to the the enterprise provisioning profile in Xcode and build the app successfully. I can use Xcode to sync it to my iPad and it runs without error there. I then email the app to a colleague and he uses iTunes to sync it to his iPad. When he runs it, the screen goes black for a moment and then returns to the home page with all the installed apps on it.
Do you have any idea what is going wrong? Where can I look for more detailed error messages? I did some digging online but don't really know where to look, since the problem is so vague. Searches on "iPad app fails on startup" or "iPad app fails on launch" yield little. Some suggest simply restarting the iPad, but I'd like to know what is really going on and solve any underlying problems.
One thing that is a little weird is that Xcode generated a .xcarchive file, not a .ipa as I was expecting, when I built an archive as Apple's documentation suggested.
I am using Xcode 4.1 on Mac OS 10.7.2 with a 4.3.5 iPad 2. My colleague has a 4.3.5 iPad 2 as well.
My question was mostly where I could look for more information. #keno's suggestion to use the iPhone Configuration Utility was spot on. It let me view the console output of the app and debug from there. Problem solved.
Regarding the weirdness about the .xcarchive being generated and not a .ipa file, I didn't notice the Share... button in the upper right of Xcode's archive panel in its Organizer window. Sharing through that button did the trick, too.
Live and learn. Thanks everyone.