Reuse CGRects don't work - ios

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.

Related

Swift - Vidyo SDK problems in TestFlight releases

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].

EXC_BAD_ACCESS at lauch for EAGLContext renderbufferStorage: fromDrawable: in Cocos2d app whie debugging

Using default cocos2d-swift app I'm receiving the error EXC_BAD_ACCESS on my iPad Mini 2 at the line:
BOOL rb_status = [_context renderbufferStorage:GL_RENDERBUFFER fromDrawable:layer];
But if I try to launch the app without debug all works fine. If I use debug on any virtual device I receive no error too.
Why it doesn't work? How to remove this error?
Looks like this is an issue on certain devices on iOS 8.3+. It works for me on almost all devices but the iPad mini 2 fails for me as well. The short of it is that there's nothing wrong with the call itself. Seems to be an Xcode bug with those devices for some reason. You can get around it (until Apple fixes it) by:
In Xcode, go to Product -> Scheme -> Edit Scheme ...
And for the Run Debug configuration (on left side) choose "Options" (on right side) and configure "GPU Frame Capture" as Disabled.
For more information, check out this thread:
https://github.com/BradLarson/GPUImage/issues/2022#issuecomment-118943746
I found the device hadn't got the last iOS version. When I updated the iOS version of the devices the error has removed.

SDWebImage on iOS 8.1 weird compile error

When I try to run project on real device (iPhone 5 and 5S with iOS 8.1) I get following compiler errors:
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:26:42: No visible #interface for 'UIImage' declares the selector 'initWithData:'
animatedImage = [[UIImage alloc] initWithData:data];
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:47:34: No known class method for selector 'animatedImageWithImages:duration:'
animatedImage = [UIImage animatedImageWithImages:images duration:duration];
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:155:21: No known class method for selector 'animatedImageWithImages:duration:'
return [UIImage animatedImageWithImages:scaledImages duration:self.duration];
My project was working normally until this morning. I changed nothing, just tried to debug on real device. The strangest part of that is I can run/debug on emulator (on any iPhone device with iOS 8) without any error.
When I downgrade deployment target from 8.1 to 8, XCode can successfully build and run the project for emulator and real device.
I tried completely removing SDWebImage and adding it back but didn't solve the problem.
I am using XCode 6.1 (Swift) and iOS 8.1 SDK on my project.
What might be causing the problem that suddenly appeared?
As has been said on other questions, the new "ModuleCache" directory within DerivedData has been responsible for many of these problems.
Here's the path:
/Users/[user]/Library/Developer/Xcode/DerivedData/ModuleCache
Simply delete the module cache, or the entire derived data directory as many have been doing on a daily basis for the last few iOS SDK iterations.
I came here looking for a different answer to a similar problem since this solution isn't fixing my current problem, but I figured I would share this as it will fix many of these.

App crashes before debugger can connect

I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.

Widevine can only run on ARMv7

When i am trying to run a video with embedded ID in the OOyala player, i am getting like "Widevine can only run on ARMv7".
NSLog(#"video id= %# ",videoID);
self.ooyalaPlayerViewController = [[OOOoyalaPlayerViewController alloc] initWithPcode:PCODE domain:PLAYERDOMAIN];
// Attach it to current view
[self addChildViewController:_ooyalaPlayerViewController];
[self.ooyalaPlayerViewController.view setFrame:self.videoPlayerView.bounds];
[self addChildViewController:self.ooyalaPlayerViewController];
[self.videoPlayerView addSubview:self.ooyalaPlayerViewController.view];
// Load the video
[self.ooyalaPlayerViewController.player setEmbedCode:videoID];
// Add observers
[self addObserversForOoyalaVideoplayer];
[self addCloseButton];
[self.ooyalaPlayerViewController.player play];
I added that line a while back when I still worked at Ooyala.
Basically, the Widevine playback library for iOS is only distributed in compiled ARM binaries. The simulator runs natively on x86, so it can't load the library (I believe is purposeful, as it makes the DRM code slightly harder to reverse engineer), and we issue a warning.
Try playing it back on an actual device and everything should work fine.
In our case, we were testing on the iPhone 5S, which can't really be ignored.
As it turns out, the issue was that we left the project files configurations as they are, which added arm64 support to the build, and that broke the player. All we had to do was override the architecture configuration in all the project files and build.
Set valid and build architectures in the build settings to armv7 and try to run the application it will work.

Resources