Am struggling to get TestFlight working with my MonoTouch app (Monotouch 5, IOS5) and have not found any MonoTouch documentation for TestFlight.
Here is what I tried so far.
Downloaded TestFlight bindings from https://github.com/mono/monotouch-bindings/tree/master/TestFlight -- after adding this as a reference it seemed that the TestFlight methods were actually not exposed at all, so I looked for another set of bindings.
Downloaded ayoung's TestFlight bindings from https://github.com/ayoung/monotouch-testflight. Built monotouch-testflight.dll with Make, copied it to the project and added to References -- this time the TestFlight methods were all visible.
Added libTestFlight.a to the Lib folder in my MonoTouch project with BuildAction set to Nothing. (I also have RedLaser in there).
Per ayoung, I enabled LLVM compiler (with ARMv7); ayoung states it is required. In Project Options -> iPhone Build my additional mtouch arguments are:
-cxx -nosymbolstrip -nostrip -gcc_flags "-lgcc_eh -framework SystemConfiguration -framework CFNetwork -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework OpenGLES -framework Security -L${ProjectDir}/Lib -ltestflight -RedLaserSDK -ObjC"
Note: The app worked ok with RedLaser before TestFlight was added to the project.
Here -lgcc_eh is as per ayoung -- I have not been able to find out what it is or what it is for. Perhaps I should have a gcc_eh.dll (?) but I don't AFAIK, and I don't know where I could find such a thing.
In Main.cs I added
using TestFlightSdk;
and In FinishedLaunching I added
TestFlight.TakeOff( "(downloaded team token is here)" );
Compiled and installed with no error (Release|iPhone).
When I now run the app on the device, it exits immediately with no diagnostic that I can discover.
The app also exits immediately if compiled to Debug|iPhone. In this case, however, if I turn off LLVM despite ayoung's strictures then in Application Output I see the following:
TestFlight: Started Session
TestFlight: Crash Handlers are installed
Thread started:
Thread started:
TestFlight: Team Token is recognized
TestFlight: End of Session
TestFlight: Communication with TestFlight is currently disabled, check earlier in your log for details
This might be because I have not yet uploaded the app's .ipa file to TestFlight?? (The app does launch in this case however.)
I am trying to find out how to generate a .ipa file. TestFlight documentation shows how to do this from XCode but my app is code-only with no .xib so that option seems to be out? TestFlight documentation also shows how to generate a .ipa from the .app file. Here my problem is, how do I lay my hands on the .app file for a device build?
Any help with these issues would be so much appreciated.
-lgcc_eh is needed to include the Exception Handling GCC library, which is often required if you link with C++ libraries.
You also have a lot of -framework options that do not look required (MonoTouch already adds them) - but that won't be the cause of your problem. If you're curious about what mtouch use/provide at compilation time then you can add "-v -v -v" to the "additional touch arguments" in your project options (and look at the build output).
As for the main issue I think it's related to the fact the TestFlight handlers are not compatible (presently) with MonoTouch (5.0). MonoTouch exception handling already provides it's own crash handlers (e.g. for NullReferenceException) and adding other handlers needs to be done with care (how and when to do it is very important). This is likely why the current bindings in monotouch-bindings don't include every feature available in testflight.
I suggest you to open a bug report at bugzilla.xamarin.com and you'll get email updates on the progress (and know exactly when the feature will become available).
p.s. try to break your issues into several (stack overflow) questions, you're more likely to receive answers that way since not everyone knows all the answers to every question you might have :-)
I was going down the wrong track entirely. Finally found the MonoTouch documentation which describes the built-in support for TestFlight:
http://docs.xamarin.com/ios/tutorials/TestFlight_Support
Will try this, it should solve the problem.
Distributing throug testflightapp is a different thing than using the testflightsdk in you app.
The first one is by clicking the upload to testflight button in the menu.
The second is by including the actual sdk.
In the last few day they (xamarin) released new testflight sdk bindings. That don't recuire you to modify the mtouch parameters. So it should be much easier to include it.
Personally i really like the testflight sdk... Helps me better (let) test my apps.
From the sound of this Xamarin bug report, it seems as though even if you get the TestFlight SDK native library working with MonoTouch bindings or by linking it yourself, you're still going to have the problem that TestFlight is not going to properly handle any NullReference exceptions and is simply going to crash the app when it encounters one. This makes the whole point of the TestFlight SDK kind of pointless until either a) MonoTouch is re-tooled to deal with it or b) TestFlight releases a managed Mono library.
Don't get me wrong, I REALLY want to be able to use the TestFlight SDK with MonoTouch. I've been beating my head against the wall trying to get it work all day. Something is failing when I call the TestFlight.TakeOff("MyKey") method. Control does return from the method, but then it crashes shortly thereafter...about 1 second after it's called. Weird.
If anyone else has gotten it work, I'd love to hear about your experiences. Thanks.
Related
I have an application that uses HealthKit and Swift in it, everything compiles and runs fine when I test it from Xcode on a simulator or a device. I tested, debugged it, and submitted it to the iTunes store. When the application was approved I downloaded the new version from the store and it crashed right away. This was extremely puzzling as I have never had this issue before. I look at the diagnostic and usage logs on my phone and the crash report for the application says this:
Dyld Error Message:
Library not loaded: #rpath/libswiftCore.dylib
Reference from: /path/to/my/app
Reason: no suitable image found.
Did find: /path/to/my/app/Frameworks/libswiftCore.dylib: mmap() error 1 at address=0x100174000, size=0x0194000 segment=__TEXT in Segment::map()
Has anyone seen anything like this or know how to deal with it?
Thank you
EDIT:
The crashing issue magically fixed itself on the morning of October 4th, which tells me that this was an Apple issue. I have been emailing iTunes Connect Support, but they have not said one way or another what happened. I also opened a technical ticket without even a response back from Apple. This is pretty disappointing, not just for the fact that Apple is not being transparent about the issue, but also it makes me feel like I have no course of action later on down the road if this ever were to happen again.
Simply do the following two steps:
1) Delete the App from the device (or simulator)
2) Clean your workspace (CMD+SHIFT+K or via menu Product->Clean)
3) Build and run your app again.
Magically helps every time with all that startup / deploy stuff...
I also often get something like "application not found on device" or signing problems etc. Minutes before everything worked well.
This appears to possibly be a code signing issue on Apple's part, and the issue seems affect apps with embedded frameworks (including non-Swift apps). There are multiple accounts of developers being affected (myself included) who had only submitted an update, without changing any build settings. Some high profile apps appear to have been affected and tickets have been filed with Apple, but there has been no official response from them at this time.
EDIT: This has been confirmed.
Edit:
The app was rejected, after making this change, for the same reason, however, I am confident that the problem has to do with a missing architecture version in the libswiftCore.
I am going to post this as the provisional answer.
Xcode 6 Standard architectures exclude armv7s
Notice how the error says: Did find: /path/to/my/app/Frameworks/libswiftCore.dylib
So it did find the lib but it also says: Reason: no suitable image found.
After running lipo against the archived build it didn't contain armv7s in the swift library, or in the app binary. I manually added it per the link above and the binary now contains support for armv7s though the swift library still did not. My app is in expedited review so I should get feedback farily quick. I will follow up when that does happen.
I had the exact same problem with one of my app version updates (FunKeyBoard 1.1).
After doing some research, looks like it was an Apple side issue for many apps updated on October 3rd. Apple fixed the issue on October 4th by releasing an update, same version number, without needing any fix/re-upload from the app developer.
Obviously an Apple side issue, but I'm surprised Apple is very quiet about it. Many developers, including myself, got angry emails from users, and poor app reviews, as a result.
This error typically occurs when signing Swift apps with certificates that lack "OU" (Organizational Unit). All certificates created after the release of iOS 8 should have this. The simple solution is to create a new certificate to sign with.
For more details, see the official Apple comment here: https://developer.apple.com/library/ios/qa/qa1886/_index.html
It seems that my on the iTunes store is now downloading and opening as expected. From what I have been reading in the Apple Developer Forums, other apps are also working now too. I have not received any word from Apple on why this happened or what caused this. I opened up a technical support ticket with them and I also contacted iTunes Connect support and there is no
explanation or any information on this issue being resolved. This is pretty poor customer service on their part.
I had the same problem. I removed support for arm64 and added armv7s and now apple review team approve the 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.
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.
So, my problem is that I'm creating a framework to be used with iOS. It works great when in the simulator and when I'm debugging it on my iPad but as soon as I send it to anyone via Testflight (including my iPad) it crashes. The application will load the splash screen, then crash.
I tried symbolicating the report but I'm not getting anything out of it.
One time happened to me... xcode compiles the app for debug on the simulator, but for release on the iOS device. Then, the debug version doesn't do many enhancements.
Go to "Product" -> "Manage Schemes". There, if I were you, I would set everything to "Build Configuration": Release.
This way, you may be able to have the simulator crash... and it may be easier for you to figure out what's going on.
In my case, I was using a block but not copying it... then, on the release version, the compiler cleared the memory while on the debug version it didn't.
Hope it helps
So, the solution to my problem was that I was linking the framework but not copying it to the device, so when I debugged it with my iPad connected to it, it would find the references to the framework, but once it was deployed, the app crashed when it tried to find the framework.
The answer was:
Go to your project's build phases.
Add build phase > Add copy files.
Choose Frameworks in the Destination field.
Copy the framework.
Your app should now have the framework copied and installed wherever it needs.
I have two projects, a Cocoa iPhone application and a static library which it uses.
I've tested it successfully on the iPhone simulator, but when I try to deploy it to my iPhone device I get (symbol not found) link errors.
If I remove the dependancy of the library the project builds/runs fine.
I have made sure all the build settings are set to iPhoneOS not the simulator.
Im sure its something simple, but has anyone run into similar problems moving from iPhone simulator to device?
--EDIT: I have managed to create new projects (one for the application and one for the static library), and successfully get them to run on the iPhone or simulator. But I have a very strange problem... for each specific project I cannot get it working for BOTH the device and the simulator... I have double checked the build settings, made sure the libraries that are being references are for the matching build settings (I believe) but I cannot resolve these linking errors.
I think I must be doing something very wrong... all the apple documentation says 'its super simple - one click' but this is giving me a lot of problems.
This is probably something to do with xCode build settings, but I cannot seem to understand why selecting the different build platforms and rebuilding the libraries does not work.
Check out my answer to a similar question for a link to an article that might help. There is a link to an interesting article.
Eventually I realised what the problem was.
I changed my device target from simulator to iPhone device, then removed the old (simulator) static library and attached the new (device) library.
All fine, except the library search path (in the build configurations) still had the simulator directory listed first, which I assume cause it to be found and used rather than the device.
This also explains why I was able to make each setting work with a new project, but only had trouble changing between settings.
Its a simple and stupid problem, but one that caused me some grief and time. Im still not sure how to properly set target dependent build settings but at least if anyone is getting similar problems its something to look out for.
I've created a complete tutorial on how to create and use static libraries, this tutorial covers the the method that is also advised by apple, maybe people will find it usefull:
http://www.sodeso.nl/?p=822
Advantages of this methods is that it automatically recompiles the library according to your project settings (so no trouble with device / simulator builds)