I'm having an odd problem drawing an NSString on the iOS simulator. Every few runs on the simulator, my app will crash with an "EXC_BAD_ACCESS" signal when execution reaches the following piece of code:
[month drawInRect:tFrame withFont:font lineBreakMode:UILineBreakModeClip alignment:UITextAlignmentCenter];
The "month" string isn't being declared incorrectly, I've set it directly before the above line and printed it with expected results, so the bad access is not related to the NSString object.
However, the really strange part of this is that it has never crashed when running on an actual device. Is this just a different in how signals are sent to applications on a device vs. the simulator?
I originally suspected that the problem lied in the font or font size that was being used, am I correct in guessing that? The font size is a little strange as it's being dynamically created. At the time of the crash, the size is '16.8286057'. However, I've casted it to an int to truncate it, and I still receive crashes. (again, no crashes on devices either)
How can I make this code more robust to fix this so I can confidently run this app on the simulator?
Related
Device: Physical iPhone X (16.0.2)
A legacy app (Objective C) of my client has worked just fine on iOS 15. On iOS 16 though, the app has suddenly 'shrunken in height'. The app opens as usual but on the top and bottom of the screen, there are black bars, as the app itself seems to be constrained to a certain size.
After some investigation, I found out that the device actually reports its Screen Height to be 480pt (iPhone X). Forcing the UIWindow to have a different size doesn't solve the issue, the app is still constrained to be the same wrong height. It seems the device 'actually believes' to be shorter than it is.
Since this behavior kind of resembles what happens when starting an iPhone app on an iPad (at least I remember seeing something like that some time ago), I was wondering whether or not this behavior is expected as of iOS 16?
If not, I would really appreciate some help here.
EDIT: I learned that +[UIScreen mainScreen] is deprecated as of iOS 16 so using that to initialize the window might be the issue. Though there seems to be no alternative for accessing this info all the way back in the AppDelegate. It was suggested to use self.view.window.windowScene.screen for reading a device's screen size, but sadly this is not accessible in the AppDelegate.
WORKAROUND:
I was not able to find the root cause of the issue but could resolve it by using storyboards to load the initial ViewController. This caused the system to automatically create a window, which was not affected by this weird system behavior.
I have a relatively simple app that runs perfectly on the simulator, but when I try and run the exact same application on an actual device I get something different, my container view shows up as completely black and elements within the content view don't show up.
Here are some images:
Xcode:
Simulator:
Actual device (iPhone):
It turns out the problem was that I had alpha of that UIView to 1 and so changing that value fixed it
I'm looking for a way I can find all UI related constraint issues while debugging my iOS app. I recently faced an issue in my production app that a UI constraint was failing and it caused an issue only on iPhone 8+. I didn't realise it while testing as even though that constraint failed on all devices, it still worked on my testing device.
Is there a strict mode which I can enable for development which would crash the app on any device if there is any constraint issue ?
Any unsatisfiable constraints will be reported in the console. If your console is too noisy, that's a separate problem, but if you really want to get slapped in the face, you can set a symbolic breakpoint:
Hitting a breakpoint will be more helpful than just crashing, since it gives you a chance to inspect the console to get details about the incorrect constraints.
There is no strict mode as such that will do it. Calculating constraints is done at runtime considering the existing device's size, resolution, etc. But you can test your app once in every size class before releasing to production. For example: iphone 5, iphone 6, iphone 10, 8plus.
Also while running the app, check for the logs and search for "NSLayoutConstraint". If there is any constraint failing, you will see those in logs when you search for that string.
I'm using autolayout to correctly lay out some views inside a UICollectionViewCell. It works fine with iOS 8, but when I try to run it on iOS 7 or iOS 6, the cells appearance varies widely everytime they are laid out (sometimes I see small changes in size and positions - one or two pixels - and sometimes big changes, resulting in some pretty messed up cells).
I swear I tried hard to find anyone with the same problem, but I couldn't. I didn't find any answer that could help me solve or even get close to understanding the problem either.
I would appreciate any inputs on how to solve or even debug this better.
MORE INFO
I'm using Interface Builder to create the view and set up the constraints. The cell's view has a total of 17 subviews, including UIViews and their subviews, and they do have a great number of constraints.
I update a UIColletionView (which includes a table of my custom cells) everytime I press a button.
What I find outrageous here is that when I run the app, everytime I press the button, the cells' subviews change their positions and sizes. I never change any constraint or frame programatically.
Also, the behavior is worst on iOS6. The frames chage a lot more and autolayout runs really slow (it take 3-10 seconds to update the collection view on iPod Touch 5th Generation, even if it has only one cell).
Worst of all, if I keep updating the UICollectionView, sometimes XCode will complain of constraints not being simultaneously satisfied. But most of the time it works just fine.
I'm also running into crashes in some devices when removing some of my autolayout-enabled views from superview. I found this is a strange behavior of Autolayout engine, which could get to some bad calculations due to float errors. I'm wondering maybe this two problems are related.
As I couldn't find any help in the entire web after searching for almost an entire day, I'm starting to think this must be a stupid error with a stupid solution. I do hope so.
Thanks in advance!
SCREENSHOTS
I'm adding some screenshots to help you visualize the problem. To get those screenshots, I run the app on iPod Touch 5th generation with iOS 6. The behavior is different on iPhone 4 with iOS 7 (it behaves much better, but I still get the elements moving around some pixels).
Everytime I press the "Update" button, I remove the view which contains the UICollectionView from its superview (the entire screen) and add it again. I do not destroy this view, it is created only once. I thought that could be the origin of the problem (some autolayout calculation buffer holding values from previous layout), but destroying it didn't solve the problem (altough it did make the displacements less frequent and disturbing, but at the cost of performance).
This is the expected behavior. This is the view I get when the app open:
Misplaced views. This is the result of pressing the "Update" button for the first time:
Result after pressing the button a second time:
Result after pressing the button a third time:
If I keep pressing the button, I get layouts alternating between screenshots 3 and 4 (or at least they look pretty like the same).
I'M GIVING UP AUTOLAYOUT AND HERE IS WHY
Well, I'm really giving up using auto layout. I've spent almost a week learning to do a lot of thing with it (specially laying out and animating views). I thought it is a wonderful and powerful feature and I learned to love it. But then I needed to support iOS6 and iOS7.
I found it only works great on iOS8 (with any device, old or not). I don't know if I'm doing something really stupid, because I can't find any threads on the internet talking about three killing problems I've been facing.
I'll list them here just in case somebody come across this thread sometime in the future with the same problem or with a solution. They are listed ordered by the priority I gave to them to why I'm giving up autolayout.
1) Performance
Autolayout runs really slow on iOS6 and a little slow on iOS7 (compared to iOS8 - remember I'm developing with XCode 6.2 and iOS8.2 SDK). The same hardware with iOS8 runs the same code just fine.
To get to this conclusion, I ran my app in two iPod Touch 5, one with iOS6 and the other with iOS8. The difference in performance was pretty clear. Loading or dismissing a simple view (11 subviews) in iOS6 could take more than 5 seconds (on iOS 8, never took more than 1). On iPhone 4 with iOS7, the same code performed much better than in iOS6, but slower than in iOS8.
I'm sure it is an autolayout related problem because, using the same code, I disabled autolayout (and size classes) for some specific XIBs and they runned stupendously fast on iOS6, while the other views kept being slow (if you are going to try this, remember to delete the old app, clean the project and build it again, or it will still use autolayout).
2) Random crashes on specific devices with iOS6 or 7 when dismissing a view controller or removing a view from its superview
The problem is clearly stated here. It seems I'm bumping into the float error problem, because I can see some e-08 numbers on the crash log.
This is a serious problem for autolayout adoption. It's a random, unpredictable - but reproducible - crash. The same layout constraint can work in various devices, with different iOS versions. But it can also crash in some of them. Example: I had a view that worked fine on iPhone 4 (iOS7) and that crashed when dismissed on iPad Air (same iOS). The solution? Change the constraint's items relation from
x.width = y.widht*0.8 + 0
to
y.width = x.widht*1.25 + 0
which is equivalent matematically, but avoided the crash.
I searched a lot if anybody had a way to know when this crash could happen or how to tackle it down forever, so I could make my views without having to worry about testing them on every device, with every iOS version, to make sure it wouldn't crash. I couldn't find a away to fix it.
This crash doesn't seem to happen in iOS8.
PS: I tried removing the constraints from all my subviews before removing the view from superview, but then the crash occurred when removing one constraint. I couldn't find any good reason to why it was crashing when removed.
3) The problem I describe in the first part of this question
It's a third priority problem because I could solve this designing the cells without autolayout. This would be a minor problem if the rest of the app do not use cells, which is the case.
But it is still a problem I cannot understand nor solve with autolayout. When I remove autolayout, the cells are displayed just fine. And they do work fine on iOS8 and I double checked if I was using some specific iOS8 feature and I'm not.
BOTTOM LINE
I'm giving up autolayout while I have to support both iOS6 and 7 or until I can find a way to fix at least the first two problems I listed above.
I've tasted the power of Autolayout and I really like it, but I can't develop worrying about unpredictable crashes hidden on some mysterious dismiss in a specific hardware with a specific iOS version. Nor can I accept the poor performance of iOS6 (sometime soon we should drop support to iOS6, though, so this will be a lost problem).
I changed the name of the app as it appears on the device under its icon by first changing the project name as suggested here.
Suddenly on the simulator:
the textures were not rendering correctly
or could could not be found ( a large x appeared where the Sprtite Halo should of been)
They were significantly freezes during run time
The textures that did render were allot smaller
After panicking a bit I undid the change and everything was back to normal.
I then changed the name by changing the Bundle Display Name, see link above.
Everything still worked fine on simulators and name did change on app icon.
To my dismay now running the app on a real device I can see the very same problems, although not evident in the emulator.
Tried deleting app from device. It looks like the device is using image from an old atlas and not rendering them correctly ie a where a small 8kb spaceship should be is a chunk of a background image 600kb although the background image is no longer in the atlas of current project!!
Interestingly the same unwanted issues are seen in both simulators and device run form Xcode 6, but app runs as expected on Xcode 5.1 simulators.
Have cleaned and built several times.
Any suggestions welcome!!
This could not be fixed, spent two days re-working an older version.
For those looking to change there project/app name please follow the documentation here.
By not following the second step caused me two days work and a mild yet uncomfortable heart attack.
The second step in Xcode 5.1.1, I had incorrectly chosen the default which had all checboxes checked and not just the Application as depicted below: