LLDB crash

I am also having exactly the same problem. Last week I could submit apps fine. This week Xcode crashes every time I attempt to.

Office Preview 15.10 works. 15.11 crashes, buggy and features don't work. I deleted office 15.11 and when back to 15.10. 15.10 Everything works that I've tried, except search in outlook which I think is a spot light issue because the results end on the day El Capitan was installed.

These sorts of discussions aren't likely to go anywhere, because they come down to dueling preferences, even when there are technical considerations, too. But one thing you said struck me:>> a good programmer deals with it just as they would deal with any other returned valueIf you accept that (as do I), I don't see why that weighs against optionals. They simply force all programmers to deal with it, and you seem to want to applaud that concept.The difference with a language (and runtime) that has explicit optionals is that failure to deal with it is going to cause an immediate crash at the point where the nil arises, not some unpredictable time later as currently. The price you pay for this consistency is a more complex source syntax, but that probably can be leveraged to help you deal with it more conveniently, after you've had time to get comfortable.Anyway, as far as Swift has concerned, this ship sailed long ago.

Hello QuinceyMorris,The reasons you pointed out for adding optionals are very good reasons I believe, and especially refering to critical systems where hidden future crashes could end-up creating unintentional harm, but why stop at enforcement of Nil values. This enforcement to avert crashes (current or future) could be applied to other valid areas in coding as well. My point is simply to leave the responsibility with the programmer and their error checking and unit testing systems they have (or should have) in place to do their job. I certainly wouldn't want to overly rely on optionals for a false sense of security.For me it's a case of where to draw the line. Certainly compiler warnings could be used instead. And then there's the new do-catch block in Swift 2.0 (like try-catch in Java)But I think the ship may still be sailing on this; I would guess (and only a guess) that we could see optionals removed in the future in favor of a warning system.

There's a theory-based answer and a practice-based answer here, and they both come to the same conclusion.Practice first: there are basically three ways to deal with unexpected missing values. You can crash (CF style), do nothing (ObjC style), or refuse to compile (Swift style). We've found from long experience that the first and second tend to lead to crashes and unintuitive logic errors in real apps and frameworks. Tony Hoare, who invented null references in 1965, refers to them as his billion dollar mistake.Theory answer: the inhabitants of a type are the possible values of that type. So the inhabitants of Int are the set of integers that fit in its size, and so on. nil is special in languages like Objective-C because it's automatically an inhabitant of *every* reference type. So when you say this is an NSString you're actually saying this is an NSString or nil and so on. Allowing people to specify this is an NSString separately from this is an NSString or nil allows them to be more preci

Hi Dex,Here are the backtraces for iOS 8 and iOS 7. The both are taken with the same project running in the iOS simulator (the behaviour is the same in iPad devices).First the iOS 8.3 backtraces, two times call willHide/WillShow. Then the same on iOS 7.1, one time call willHide/WillShowReagards.Sebastien.iOS 8.3 :---------2015-06-19 11:49:36.674 TestKWS[12305:761940] Keyboard will hide(lldb) bt* thread #1: tid = 0xba054, 0x000000010fe489d0 TestKWS`-[ViewController keyboardWillHide:](self=0x00007fa84381e1d0, _cmd=0x000000010fe48ec6, notification=0x00007fa843869890) + 64 at ViewController.m:57, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1 * frame #0: 0x000000010fe489d0 TestKWS`-[ViewController keyboardWillHide:](self=0x00007fa84381e1d0, _cmd=0x000000010fe48ec6, notification=0x00007fa843869890) + 64 at ViewController.m:57 frame #1: 0x00000001106b054c CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 frame #2: 0x00000001105aea04 CoreFoundation`_CFXNotificationPos

Submit using Application Loader now works and binary is accepted, but Xcode still crash when trying to submit