I have a complex application that when it has been asleep for while and it is relauched shows a complete backscreen.
It's very difficult to reproduce this (I haven't managed with the simulator).
My question is simple I would be the best way of troubleshooting this and what could be the cause of this issue.
I'm using the AsyncDisplayKit framework heavily (this might cause something). I'm developping for iOS9 in Swift.
Thank you in advance
Related
I've got a frustrating problem here in that my iPhone app seems to run fine in XCode (running in the simulator or debugging it with iPhone plugged in), but archive versions act differently.
My sprites are supposed to perform movement only in a strict grid pattern and at constant speeds, but they are sort of skipping around and moving in unexpected diagonals.
I don't think it's IOS7-related because the problem doesn't manifest in the new version (7) of the simulator.
I never saw this problem in months of development and dev testing. It only seems to have started happening since I started producing and distributing archives.
App details:
Game, cocos2D
Hardware:
MacBook Air, iPhone5, IOS7
I ended up getting some help from someone on the Apple Developer Forums, but I'd like to update this posting as well, even though it's redundant.
I've been running XCode for over 2 years and I didn't realize build configurations could cause different behaviour.
By setting the Run scheme to use the Release build configuration I was able to re-create the problem on the device.
The problem still existed of course, but this posting I found suggested turning off compiler optimizations to solve a vaguely similar problem.
That did it. Somehow the calculations that occur to control sprite vectors in my application behave strangely with compiler optimizations turned on.
I started to work in an App that needs to be optimized for iPhone 5 and requires iOS 5.x or later.
But the scenario where the user has and iPhone 4 with iOS 5.x is possible. But the Autolayout will be a problem on those cases...
So, I could use Autolayout for iPhone 5,but the users with iOS 5.x(iPhone 4 or below) will have problems, so in order to avoid that, should I have two nib's one for give support to the iPhone 5 screen and another iPhone 4? (And that sounds very ugly to me).
Having something like this...
if(IPHONE5){
//Load iPhone 5 nib with AutoLayout or without it
}else{
//Load iPhone 4 or below
}
In any case, is there a better option to give support to both screens but with different iOS versions? suggestion on this?
Since now thanks
This is something that I had been wondering about myself. However, I stumbled upon a webpage: "Drop iOS 5: Only support iOS 6" that explains that such scenarios if possible, should be avoided.
Doing development for older OS's might seem reasonable, however...
the rate in which people update their phones is extreme fast (unlike Android)
the development time increases
development costs increase
maintaining code more complex
release dates become later
as a result:
more people have upgraded to the newer OS
your 'older share' has become less relevant
your 'lost sales' is even smaller
your 'return of investment' because of increased cost has extended
My advise: drop iOS-5
Check out this project at Github, it might be helpful
https://github.com/RolandasRazma/RRAutoLayout
Basically it can help you handle some AutoLayout features on iOS5.x. But as this is done with some hack to the internal classes you should be careful if you would apply this for an application that will be shown on the App Store.
Anyway it can help you understand the manage needed for doing this.
But, I would recommend to keep with the 'separate nibs' method.
Hope that helps,
Almost every time I use the iPhone Simulator, I get intermittent slowdowns. Everything is running smooth and then the whole UI randomly drops down to 1-5fps. View pushes, animations and everything related to the UI just becomes sluggish for 2-10 seconds. Then all of sudden it comes back to normal again.
I've googled this issue several times and just can't find a solution. My guess is that there's some 3rd party extension/plugin that's causing this slowdown, but I'm not sure how to debug this.
This has been the case for the last 4 SDK installations. Happens on all simulators (iPhone, iPhone 4 and iPad). Happens in my own apps as well as in Apple's stock apps (Photos, Safari, Settings) and even in the Home Screen.
This issue makes debugging/testing extremely annoying. Any guess what could be the issue?
Ended up deleting everything in the ~/Library/Application Support/iPhone Simulator folder. It had some really old folders back from the 3.0 days. Maybe some incompatibility, I'm not sure.
Haven't had the issue since.
EDIT: Nope, this is only a temporary fix. Still looking for a permanent solution.
I know it's been a while, but it seems like Xcode 4.2 fixed this for good.
I noticed some slowdowns in the simulator when FaceTime for Mac is running, but it's not as bad as you describe. Have you tried when nothing else is running on your Mac?
Total long shot: Are you using Core Location at all? (GPS Stuff)?
I have seen the same kind of behavior your are talking about when I turn location tracking on inside my simulated iPhone app.
Does anybody know of a 3rd party profiler for XCode with the iPhone?
I really don't like instruments, it's a pain to try to figure out whats going on. Allocations and leaks are fine, its just the CPU Sampler that I don't like.
I really liked Shark but they have stopped updating that and it doesn't work with iOS4.
I doubt that there are any, since (as far as I know) there is no published documentation from Apple as far as the protocol to use when communicating with the iPhone and attempting to profile a running application.
I'm trying to get BNRPersistence running in an iPhone app, but I'm having a problem that I have no idea how to solve. Keep in mind I'm relatively new to iPhone dev.
The problem is that BNRStoreDocument subclasses NSDocument, which exists in the Cocoa framework and thus isn't available on the iPhone. So obviously I'm getting compile errors that it can't find NSDocument. The developer of BNRPersistence states that it works on the iPhone, so I'm sure there a solution, I just don't what it is.
Any help would be greatly appreciated!
The iphone Demo project does not have BNRStoreDocument in it but just BNRStore. I think is reasonable to assume that BNRStoreDocument is only available when running under Cocoa on a Mac OS X.
The BNRStore is an analog of NSPersistantStore. I'm pretty sure that's what you should be using on the iPhone.