I'm currently using Vidyo iOS SDK on Swift.
Everything works great, except for the TestFlight releases of the app, that works different from local installations (directly from Xcode).
The problems come from the initialization of the VCConnector for custom handling of views, (nil instead of UnsafeMutableRawPointer(&vidyoView)).
connector = VCConnector(nil,
viewStyle: .default,
remoteParticipants: 10,
logFileFilter: UnsafePointer("warning"),
logFileName: UnsafePointer(""),
userData: 0)
The resulting version in TestFlight will not display the self camera (the preview of my video).
Has it occurred to someone?
If you are uploading to TestFlight then it's likely a release build where speed optimization included Speed [-O].
Try to switch onto default one (for release): Build Settings -> "Swift Compiler - Code Generation" -> Optimization level: No optimization [-Onone] OR Optimize for Size [-Osize].
Related
I have made an app that tracks 2D body motion data using the back camera. I have followed Apple's example to create an ARView from the storyboard, and have added this code in my viewDidAppear:
arView.session.delegate = self
// If the iOS device doesn't support body tracking, raise a developer error for
// this unhandled case.
guard ARBodyTrackingConfiguration.isSupported else {
fatalError("This feature is only supported on devices with an A12 chip")
}
// Run a body tracking configration.
let configuration = ARBodyTrackingConfiguration()
arView.session.run(configuration)
When I open the app everything works perfectly when installing from Xcode, but the app crashes when installing from TestFligth. Crash log shows me the last backtrace log at arView.session.delegate = self
I've found a workaround in case someone faces the same problem. According to Apple this is a known issue in XCode 11. To solve it, you need to manually add RealityKit to your target’s Link Binary with Libraries build phase. Hope this helps
I am getting the following error messages when our production iOS app initializes:
[Crashlytics] Version 3.8.4 (121)
[Crashlytics] Running on iOS Simulator (iPhone), 10.3.0 (16E195)
[Crashlytics:Crash] Reporting is disabled
[Crashlytics] Crash reporting could not be initialized
[Answers] Initialized
[Fabric] Initialized with kit versions: {
"com.twitter.answers.ios" = "1.3.4";
"com.twitter.crashlytics.ios" = "3.8.4";
"io.fabric.sdk.ios" = "1.6.11";
}
Every subsequent call to log an event gets the following error:
[Crashlytics:Crash] WARNING: CLSLog has been used before (or concurrently with)
Crashlytics initialization and cannot be recorded. The message was: ...
The non-production versions of the app work fine running the exact same code but with different bundleIDs. Normally when the app initializes for the first time, then I see the app populate in the Fabric dashboard, but in this case the app is not showing up.
We have an Android and an iOS version of the app, and they both use the same bundleID, so I am wondering if there is a conflict because of that? I see the Android version of the app in the dashboard, and it seems to be working properly. This is an app that originally was a Xamarin app that compiled to both platforms, neither of which incorporated Fabric/Crashlytics. We have now written native apps on each platform, and both are using Fabric/Crashlytics.
Since this is a pre-existing app in both stores, we do not have the option of changing either app’s bundleID.
Make sure you initialize Crashlytics with Fabric before calling any Crashlytics methods:
Fabric.with([Crashlytics.self])
One step I routinely miss is to make sure you've added the build phase on your target:
"${PODS_ROOT}/Fabric/run" ${FABRIC_API_KEY} ${FABRIC_BUILD_SECRET}
and either replace ${FABRIC_API_KEY} and ${FABRIC_BUILD_SECRET} with your key and secret or add custom build settings for each.
There are apparently cases where Crashlytics does not auto-activate new apps so that they show up under your list of apps, even though everything is coded correctly and data is going to their servers. In this case, send an email to Crashlytics support (support#fabric.io) that contains a copy of the info.plist entries for the app in question and they will activate it for you. I have had to do this several times, especially with app extensions.
When I finally traced it down in my situation, the error was entirely correct, but not obvious.
I saw these errors in various testing targets where the code we tested was using a custom logging wrapper which called CLSNSLogv(), but the test didn't actually go through the AppDelegate and therefore did NOT initialize Crashlytics. After trying a few things I was convinced that it worked when executed as an app, but in our configuration it was not working under the unit test configuration.
I'll likely alter our custom wrapper to bypass CLSNSLogv() during testing anyway. The biggest benefit of using that is when crashes occur on devices, so we won't be missing anything.
I've got 3 iPhone 5, 2 iPhone SE, 2 iPhone 6, an iPhone 6+ and an iPhone 7.
I've found that my app which uses a call directory extension won't work on any of the three iPhone 5 devices but there's no problem with it working on the other 6 assorted devices.
In case there is some problem with my app, I created a new app with a call extension which was created entirely using the XCode project templates (the Xcode call directory target template creates a lot of boilerplate code which is fully functional and will run and work without further change).
I got the same results - the template app also does not run on any of the iPhone 5 but it does run on the other 6 devices.
The conclusion from this would appear to be that for some reason call extensions don't work on an iPhone 5, however this is not a correct assumption because I downloaded an app from the app store (Hiya) which uses call extensions onto an iPhone 5 and there were no similar problems with its call extension.
So it is a mystery to me why both my app and the Xcode template app both do not work on any of my iPhone 5 but they are fine on every other device.
And that therefore is my question - has anybody encountered a similar situation or has any speculation why they don't work on iPhone 5?
(Was there an architecture change after iPhone5 and the build settings of the call extension might need changing to get it to work on the iPhone 5 for example?)
The way my app and the Xcode template app fails on the iPhone 5 is the same
1) the extension does not appear in Setting | Phone | Call Blocking & Identification. This implies it may not have installed/registered with the OS properly, however I don't see any problems being logged by the OS in the console when looking at the OS logging.
2) The status of the extension cannot be queried on an iPhone 5:
let theExtension = CXCallDirectoryManager.sharedInstance
theExtension.getEnabledStatusForExtension(withIdentifier: "com.redacted.redacted.CallDirectoryApp.TheCallExtension") {(enabledStatus, error) -> Void in
if let err = error as? NSError
{
print ("\(err.code) \(err.localizedDescription) \(err.localizedFailureReason)")
}
}
The error is err NSError domain: "com.apple.CallKit.error.calldirectorymanager" - code: 1
Again this might indicate the problem is related to the extension not installing.
(The problem is independent of the version of iOS 10 used on the iPhone 5, its the same result with a few versions of both beta and non beta versions. All devices are registered on the provisioning portal)
The iPhone 5 is 32 bit and everything else is 64 bit. I changed Xcode's default settings for the extension to the following and it now works:
I have found that my Mono for Android app crashes on each start after the user goes to Settings->Apps->MyApp and selects "Clear Data". I created a new project with the Mono for Android "Hello World" application, and this app exhibits exactly the same behaviour, which leeds me to the assumption this happens somewhere in the mono stack away from my control. If I check with adb logcat, this are the relevant lines that I can find:
I/ActivityManager( 185): START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=Test_App.Test_App/test_app.Activity1} from pid 386
D/dalvikvm(18358): Late-enabling CheckJNI
I/dalvikvm(18358): Turning on JNI app bug workarounds for target SDK version 8...
I/ActivityManager( 185): Start proc Test_App.Test_App for activity Test_App.Test_App/test_app.Activity1: pid=18358 uid=10074 gids={3003}
D/dalvikvm( 119): GC_EXPLICIT freed 37K, 3% free 12553K/12867K, paused 1ms+2ms
I/ActivityThread(18358): Pub Test_App.Test_App.mono.MonoRuntimeProvider.__mono_init__: mono.MonoRuntimeProvider
D/dalvikvm(18358): Trying to load lib /data/data/Test_App.Test_App/lib/libmonodroid.so 0x4168ba48
D/dalvikvm(18358): Added shared lib /data/data/Test_App.Test_App/lib/libmonodroid.so 0x4168ba48
D/dalvikvm( 119): GC_EXPLICIT freed <1K, 3% free 12553K/12867K, paused 2ms+2ms
E/mono (18358): WARNING: The runtime version supported by this application is unavailable.
E/mono (18358): Using default runtime: v2.0.50727
D/OpenGLRenderer( 386): Flushing caches (mode 1)
D/dalvikvm( 119): GC_EXPLICIT freed <1K, 3% free 12553K/12867K, paused 1ms+1ms
I/mono (18358): Stacktrace:
I/mono (18358):
D/OpenGLRenderer( 386): Flushing caches (mode 0)
D/Zygote ( 119): Process 18358 terminated by signal (11)
I/ActivityManager( 185): Process Test_App.Test_App (pid 18358) has died.
W/ActivityManager( 185): Force removing ActivityRecord{41a85018 Test_App.Test_App/test_app.Activity1}: app died, no saved state
Does anyone have the same behaviour in his mono apps? Is there a fix?
Managed to solve my own question. Under project settings I had to go to "Mono for Android Build" tab, select the Release configuration and make the linker "Link all assemblies" instead of "Link SDK assemblies only". Fixed this by trial and error, but what can you do..
Another solution I've found is to disable the use of the "Shared Runtime" when building the app.
In Visual Studio this is on your Android project settings, Android Options > Packaging tab > Packaging properties > Use Shared Runtime (untick)
It makes the resulting APK a bit bigger, but means users can do "Clear Data" on your app, restart it and it will run without crashing!
Using Visual Studio 2015 with a Xamarin Forms app on an LG G3 Vigor as a test device. Everything worked fine for many months. I was doing testing for performance documentation so I decided to do Clear Cache on my app in Setting -> General -> Apps on the Vigor. After that was done the Vigor would cause a runtime error when I would deploy my app to the device. The app would work fine on other devices, emulators and iOS simulators.
I tried other suggestions listed on this post. I ended up doing a factory reset on the device. After unlocking developer mode and reconnecting to my computer, it now compiled and ran the app again.
I think a person could try to revoke usb debugging authorizations and re-authorize if they didn't want to do a factory reset, to see if that gets things working again. This may create a different connection path between VS2015 and the device that resets whatever issue was caused by the cache reset. If all else fails, a factory reset did it for me. Hope it helps in case this happens to someone.
I have an strange behavior on reusing CGrects in ipod touch 2G, but not in 3G 4G.
When I run the app from XCode4 with the device plugged it works just fine, but when I archive the app and upload it via itunes or through web server, comes the weird behavior.
If I go to edit scheme, select Archive and choose Build configuration: Debug, upload the app through web server, it works fine.
my code is like this
//this code works perfect
CGRect pos = self.toolBar.frame;
pos.origin.y = 0;
self.toolBar.frame = pos;
//this code fails, to fix it I need to create a new CGRect (CGRect pos2)
//or assign an CGRectMake to pos
pos = self.picker.frame;
pos.origin.y = self.toolBar.frame.size.height;
self.picker.frame = pos;
What is causing this problems. How can I compare those builds configurations (debug - release)
Edited
The main difference between running from XCode vs. archive is DEBUG vs. RELEASE builds, and in particular compiler optimization which is enabled in your release build.
You're likely seeing an LLVM compiler optimization bug related to armv6 processor, I had something very similar happen to me. Try switching from LLVM to GCC compiler. Does this resolve your issue?
Further, if you upgrade to XCode 4.5, you'll find that ARMV6 has been deprecated, so you can also choose to drop support for these old devices and be lockstep with Apple.