Starting from iOS 9 (I used Xcode 7.0 beta 6 (7A192o)), an Objective-C app with UITextView will hang if the text view's text is less than 10 characters. CPU usage goes up to 99-100% and the whole system hangs.
How to reproduce:
Create a brand new single view app from template (or anything else).
In storyboard, add a UITextView with default settings anywhere in the main view.
Set the text to a string that is less than 10 characters long.
Launch the app in simulator (any device, as long as it's iOS 9).
Upon launch, before displaying the single view, the system will hang and CPU usage will go to maximum forever.
Set the text to any other text that's more than 10 characters and the app runs correctly.a
Looks like constraints or any other settings do not affect this behaviour.
The immediate solution would be to simply not have less than 10 characters, but, well, that's lame.
You can check out this github repository that also demonstrates the problem.
I also submitted a bug report to Apple (bug no. 22736256, although you probably can't see it there yet).
Weirdest. Bug. Ever.
Is anyone also encountering this one??
Took me half a day to narrow the error down to a UITextView. This has got to be the stupidest bug ever.
You don't need to ensure that the UITextView holds at least 10 characters. Just adding a default of at least 10 characters to the UITextView in Interface Builder will fix the problem. Then, you can empty the UITextView using code.
By the way, this is an Xcode 7 bug, not an iOS9 bug. New builds built using Xcode 7 will create the same problem in iOS7 and iOS8.
According to the release notes of Xcode 7.1.1 this should be fixed now:
Storyboards and nibs containing UITextView elements with between 1 and 11 characters no longer hang when loaded on iOS. (23264732)
Refer the blow. It is a bug in Xcode 7 and still has not been fixed.
http://xcode7criticalbug.blogspot.in/2015/10/uitextview-bug-in-xcode-ios-app-getting.html
It can overcome by programatically setting the text property for UITextView.
i have found the solution first check the memory leak and please add the this line of code in particular class.
-(void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:YES];
}
This is helpful for me my problem is resolved.
Related
My storyboards are created in Xcode 7. After I installed Xcode 8, all of them are constantly messed up. When I open one of them, Xcode asks me to select a device (which is a nice new feature). But then it never adjusts views' frames, so I must press "All View: Update Frames" infinite amount of times. And even this doesn't fix all "misplaced" views.
Anybody knows how to fight this problem? Or the only option is to pray that Apple fixes it at some point?
UPDATE 1
It happens every time I open IB, even if I've fixed frames previously.
UPDATE 2
When my colleague fixes same storyboards on his computer, changes stay. No idea what makes my Xcode so special.
I figured out the following workaround
First, set width and height for your view to the values it will calculate on selected device in your storyboard, then preserve superview margins.
This worked for me
Xcode 8.0 has the bug, that it does not save the rects from the storyboard xml-s. So if you fix misplaced views in Xcode 8.0, the problem is gone for as long as the storyboard stays in RAM. When the storyboard is closed and re-read from a file, the issue appears again. (Actually Xcode 7.0 had exactly the same problem in the beginning.)
Xcode 8.1 beta 3 (the most recent version at the time of this writing) fixes this issue:
frames are not 1000x1000, but they stay as they were.
I have an iOS App that is targeted to iOS 6 and above (I know, I know. But a disturbing number of our users are still on iPhones that have never been updated) and I'm seeing a warning when I compile my app:
Justified or Natural text alignment before iOS 7.0
This is seen for each place I've chosen "natural" text alignment for a control in my xib files. This is confusing to me, because the docs clearly state that NSTextAlignmentNatural is "Available in iOS 6.0 and later."
NSString Documentation
No warnings are presented when I set the alignment in the code, only from the xib.
Unfortunately, I am unable to test this myself because I don't have an iOS 6 device. Is this a warning that I just need to ignore, or could issues still arise in the older devices?
I just made a test project and got the same result with a UILabel set to justified. I repeated with a UITextArea and didn't get the error, so it seems to only relate to setting justified on UILabels.
I ran the same code on an iOS 6 device I have here and didn't get a crash, it just stayed left aligned, so you can probably ignore it, but it is very odd.
Perhaps you could try setting attributed text on the UILabels instead and see if the same thing happens.
UILabel set to Left-justif,like this
setting
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 use the UIKeyboardTypeDecimalPad in one of my apps, but when running on iOS 8 the comma button is capped at half width.
I tried creating a simple app with only a UITextField and the DecimalPad keyboard (in both Objective-C and Swift), it exhibits the same issue. Is this a bug in UIKit? I have not been able to find much information online, and iOS 8 has been out quite a while now. In iOS 7 the same code displays correctly.
This is a really annoying oversight from Apple. The only real solution will come from them.
Otherwise use the number pad and add the '.'. I did that before the DecimalPad came out.
I am coming across a strange bug in my app, that I believe is an iOS 6 bug.
I have a UITextView that contains some text that has some links and phone numbers. In my storyboard, I have Links & Phone Numbers checked under 'Detection' for my UITextView. In code I also do:
_txtvFooter.editable = NO;
_txtvFooter.dataDetectorTypes = UIDataDetectorTypeAll;
The issue I am having is a strange one, but when I run my app onto my device (or sim) from Xcode, the UITextView detects all of the links fine, and I can click them. If I then run the app not in debug (not running through Xcode), the links show as black standard text and cannot be touched. Note this is only happening on iOS 6.
On the iOS 5 simulator, the links show as blue and are clickable no matter if the app is run in debug, or just ran from the simulator.
I have looked all over the internets, and cannot find a solution or anyone else who has reported this issue. Does anyone know if something changed in iOS 6 specifically? I thing is, like I said it detects the links when run straight from Xcode, so to me it seems like an iOS 6 bug.
Any help is appreciated!
I found what was causing my issue. What I was doing was placing a UIView in the footer of a UITableView in Storyboard that contained a UITextView.
The fix was dumb... I removed the UITextView from the UIView and just used that as the footer (I at one point had multiple textviews in the footer) and the links began detecting.
I still believe this is a bug though-- because if you do need to use a UIView the links would not detect from the textviews within.