Xcode Beta 6.3 magically delegates tasks to other threads? - ios

We've came onto this strange bug in our project (I hope it's a bug not just our fault). Let's jump straight into the problem.
Our application is Storyboard based, of course it connects to the external API etc. But we've faced this strange thing that regular implementation of prepareForSegue: and things related to segues automagically delegates things to other threads. Just a small example - when I do NSLog(#"Sample log") in viewDidLoad it doesn't get fired when it should but it gets called in the random time that's why I guessed that something might get delegated to the other-than-main thread. Firstly I thought that the networking layer may cause this because of blocks and so but even when I put direc logs into the application they get called in a random time! We've tried to check the thread in debugger and it shows us thet everything happens in the main thread. Strange, right?
Anyway, my colleagues check this against the different versions of Xcode because on my machine there are bothe 6.2 and 6.3 Beta. When we compile this on a computer with only 6.3 installed everything works properly! Is it possible that 6.3 Beta introduces some changes which handles segues differently than previous versions? Or maybe we should start seeking for the troubles some oher place?

Related

Swift sometimes calls wrong method

I noticed strange behaviour during working with Swift projects. I can't explain it other than Swift sometimes calls wrong method. It is very rare and even adding blank lines to the code could lead that this error is gone.
Let me explain in screenshots what I mean, next I use CoreData example of SwiftDDP project that can be found on Github, but such issues I was able to see in my own projects.
Here we at Todos.swift:74 where you can see breakpoint, I expect that next call should be getId() method of MeteorClient class because it was already instantiated:
After Step Into as you can see the ping() of the same instance is called:
The next two steps into lead to EXC_BAD_ACCESS exception:
In my project I saw this issue fairly often before I stopped using singletons, so it could be related to Swift static memory usage or I don't understand something that is not surprising as I have little experience with multithreading and memory management.
My environment is:
AppCode OC-145.184.11
Xcode Version 7.2.1 (7C1002)
iOS 9.2 SDK
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81)
NOTE: Here I use AppCode but the same behavior I was able see in Xcode, and even more if the same issue that reproduces in Xcode could not reproduce in AppCode and vice versa.
Would be thankful if someone can explain this strange behaviour to me.
Thanks!
This just happened on my team, using Swift 2.2. It's really incredibly strange. It's not a threading issue or an async problem, it was a very cut & dry use case. We called one instance method and another one above it got called. I deleted the method that was getting called, and then the one above THAT got called instead. Then I moved the method I was actually calling to a different location in the file, and it looked like multiple properties were getting called.
This is disturbing and worrisome, as now you feel you can't trust your code to run properly.
But we did "solve" it. We moved the method up to the code that was actually getting triggered, and after a little trial & error the right method got called. Not yet sure if this will manifest itself for other methods.
It'd be nice to be able to provide a simple project where this is happening, but it seems highly unlikely that it's possible, and I can't share a snap shot of my code base with Apple. It must be a perfect storm of something to cause a bug with Swift's run time.
I had a similar issue, I think. Couldn't see that the wrong function was being called, but breakpoints on the function that was being called were never hit, and I couldn't step into the function from where it was being called. I added a new function (I called it wtf) with the same parameter list and implementation, and that one worked as expected, so it must have been a weird linking issue in the Swift compiler.
Update: super-cleaning appeared to work (see below), but it doesn't. Looks like I'm leaving my wtf function in.
After super-cleaning the project, it looks like everything's working as expected again:
clean (cmd + shift + k)
clean build dir (cmd + opt + shift + k)
quit XCode
delete derived data (rm -rf ~/Library/Developer/Xcode/DerivedData/*)
FYI, in my case, the function I call is in a generic base class, called from a generic subclass, triggered by a specialized sub-sub-class. As we all know, the generics are still very buggy in the Swift compiler, so that's probably why I encountered this.
Do you have multiple threads running? Maybe a network thread?
I thought I had this issue too but then it turned out my one thread was doing something and because the other thread crashed it stopped the other thread at a random point. I only noticed this thread so it seemed like it crashed at a random #IBAction function.
When I switched to iPhone 6 simulator instead of iPhone 7, it seems to be working correctly now!
Our app was rejected from review because of a mysterious crash. After debugging I found that it was having this same issue - but only for the Release scheme!
So I went through every setting in Build Settings one by one to see if switching it to that of another scheme would fix the issue: changing ENABLE_TESTABILITY to true fixed it......

How to get SKAction(name:) to work reliably?

I've been working through the DemoBots example and having a lot of trouble getting it to work on all devices.
https://developer.apple.com/library/prerelease/ios/samplecode/DemoBots/Introduction/Intro.html
The current problem I'm having is that on an iPad Mini the app launches but crashes when loading animations. It crashes in AnimationComponent.swift on the line that loads an action from a file:
let bodyAction: SKAction?
if let name = bodyActionName {
// crash here
bodyAction = SKAction(named: name)
}
else {
bodyAction = nil
}
Debugging the app reveals that its trying to load an SKAction called "ZappedShake" but crashing with an array out of bounds exception.
On an iPhone 5S it runs fine. My best guess is its race condition with the faster iPhone 5S is loading the file with the action serialized in it, and by the time execution reaches this point the action is available. But on the single core older iPad the file is not yet loaded and the call fails.
Both are real hardware running iOS9 13A4325c, compiled on XCode Version 7.0 beta 4 (7A165t).
Making the problem more difficult is that I can't see where the file that apparently creates the "ZappedShake" - ReferenceActions.sks - is actually loaded. Its referred to by ReferenceScene.sks but nowhere in any of the code or anywhere else in the project can I see that file being referred to.
Is there some sort of name convention magical file loading mechanism for SKActions? Why does it work on the iPhone 5S and not on the iPad?
UPDATE: Found more on this here: http://asciiwwdc.com/2015/sessions/604
Also this year we focused on referencing and instancing.
We know you spend a lot of time designing high-quality content and animations for your games and we want you to let you reuse that content anywhere where you would like to.
We're allowing you to create serialized data files for your nodes and your actions and then add them as a reference instead of just loading them into your scene.
This way, every time you make a change to the source asset that is automatically reflected in the content of your game.
How do I do this for nodes? For nodes I design part of my scene, maybe a background element, or some scenery in our editor with an Xcode and then I can just drag-and-drop those files into my main scene in Xcode and it will automatically create a reference and it is all set up for you.
If you want to do this in code you can as well, you can manually construct an SKReferenceNode, assign it a file name or even a URL and when that content is first presented in your game we'll load in that content based on the latest version of the file that's in your bundle.
We can also do the same thing for actions. With actions go check out our great new action editor and beyond creating and composing the actions in Xcode you can give all them names.
These names are the key to using them in your game. We have added a selector to SKAction called actionNamed. This works just like it does for SKTexture and textureNamed.
You pass in the name of the action you want. We're going to automatically look inside of your app bundle in all of the serialized action files, find the one with the appropriate name and then surface that to the application.
This looks great but I can't find any documentation on it, or figure out how to debug it when it goes wrong.
It's not you, it's iOS. There's a bug with action references affecting 32-bit devices (like the iPad Mini.)
This issue has been fixed in iOS 9.2 Beta 1, according to this thread on the Apple developer's forum:
https://forums.developer.apple.com/thread/17267
Try running on a more recent 64-bit device (like iPhone 6) in the simulator. Or try upgrading your iPad Mini to iOS 9.2 Beta 1. Or just wait for the next iOS release to fix the problem.
The DemoBots game seems to run reliably when compiled with Xcode Version 7.0 beta 6 (7A192o).
Using a different machine (my home laptop) with a fresh install of Xcode the problem goes away. I also note that the first time I tried there were a few minor compile fixes I had to do such as renaming CGPoint.zero to CGPoint.zeroPoint which I guess should have sounded warning bells that there was some sort of version conflict. This time with the fresh install it compiled and ran out of the box.
I still don't completely understand how the reference actions are getting picked up but at least I now have multiple working versions of Demobots so I can just duplicate the working code there.

Only code completion / code sense which starts with # is not working in Xcode 6

Suddenly, only code completion which starts with # has stopped working in all Xcode projects in Xcode 6.
About a week ago, after upgrading to Xcode 6.0.1, I tried to use Debug View Hierarchy, then not only Xcode but also my entire Mac system crashed and it restarted. Since then, if I remember correctly, The problem has started to happen.
Most code completions are working correctly, like NSLog().
But, only code completion which starts with #, like #"string", #[array, ...], hasn't been working in all of my Xcode projects. When I type #, I can't see an automatic code completion popup window for NSString, id, NSArray, and so on. The code completion popup window automatically doesn't show up, but when I type the esc key, it shows up.
I tried deleting Derived Data from Organizer in Xcode, but It didn't solve the issue.
I updated Xcode to 6.1 just today, but it didn't work.
I tried re-installing Xcode 6.1 with deleting all files at ~/Library/Developer/Xcode, and it didn't work either.
Even in a new Xcode project, there's the same issue. One of the weirdest points is that this code completion issue happens in my all Xcode projects regardless of when they are created. Also, the code completion for only # doesn't work.
The code completion for # is used very often. It's a sooo pain in the neck... It would be great if you could give me any advice to solve this issue. Thanks!
I believe Apple has changed the behavior of this. So I guess get used to it.
I know it sucks, but at least you can change it to something else.
If someone knows how to get it back to like in Xcode 5 that would be awesome!

Auto Rotate quit working after upgrading to MonoTouch 6

I made a project with MonoTouch 5. After upgrading to MonoTouch 6 my UIViewControllers are not auto-rotating anymore. These are hosted inside a tabviewcontroller. I get this warning:
ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' overrides obsolete member `MonoTouch.UIKit.UIViewController.ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)'. Add the Obsolete attribute to ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' (CS0672)
But the method still gets called when I am debugging. The new ShouldAutorotate never gets called. Any ideas? Thanks!
There can be a few reasons. One of them is that you should be (if not already) setting the RootViewController in your AppDelegate (another link here). That was not required before iOS6.
Another one is starting to use the new iOS6 API, without keeping a fallback for earlier iOS versions. That would match your comment, i.e. works on 6.0 but not on 5.1.
Note that since you're still targeting iOS 5.x you can safely ignore the obsolete warnings. iOS 6 introduced new API to handle rotation but it will automagically fallback to the old API to keep compatibility with existing applications.
That also means that if you start using the new (iOS6 only) API then you'll need to handle the old API yourself or rotation won't work with iOS 5.x.
Honestly I think that's a testing nightmare - you're better off letting iOS handle this and keep a single code path to handle rotation. That why I strongly suggest you to keep using the older API until your deployment target minimal version becomes iOS 6.0.
I had the same issue after upgrading and I got the answer to my problem over here. Here is the heart of the problem, quoted from the link:
Application windows are expected to have a root view controller at the end of application launch
So if previously like me you have this in your FinishedLaunching(UIApplication app) method in main.cs:
window.AddSubview(mainVC.View);
Replace it with this:
window.RootViewController = mainVC;
That's it! Happy days! Rotation works again. :) At least it solved the problem for me.
I don't know whether this small thing causing the application to go wrong is Apple's fault or Monotouch/Xamarin's fault, but I think that the Xamarin team should do something about this. Surely this is something that could be detected and corrected at compile time?
Anyway. Hope this information saves other people the hours that this issue has cost me!

XCode 4.2 on OSX 10.7.1 (Lion) Crashing/Locking Up all the time. Anyone Know how to fix?

This should not create any Issues with the NDA as I am not asking anyone to reveal any functionality of the application, I have asked on the Developer Forums, but They dont have the user base or the response speed of StackOverflow.
I have been working with XCode for a while now. And other then these issues, I REALLY LIKE the new xcode. I will (when these issues are resolved) recommend this application to all iOS/OSX developers.
Anyhow.
I am currently developing iOS applications. And am Running this setup on Mac OSX 10.7.1 (Lion)
Issue 1:
If I use the Interface builder it will first of all stay open even after I navigate away from it and it is no longer visible or to my knowledge "running". After a while it will consume more then 4 gigs of active memory. I will have the activity monitor open and Will eventually have less than 20megs left of free memory. I upgraded my MacMini to 8 Gigs of memory and at this point it will get down to about 200 Megs of memory left and will eventually release the memory that IB had held onto. If I do not open IB in XCode 4 it tends to use a lot less memory. (adding 8 gigs of memory makes this memory leak a lot less of a problem)
Issue 2: (MOST ANNOYING, HOPING FOR A FIX TO THIS ONE MOST)
This one only currently happens on one of the Three machines I code on. And what happens is while programming if I [Run] the app it will work for a while. Then at some point through the process it will begin to Lock Up when I press Run or Command-R. If I save the code file and run. It will not lock up. However if I forget to save, It will not only lock up. But will force me to terminate the XCode app, and Subsequently Recode everything that I had edited since the last save and the Application Run. This is by far the most annoying bug I have encountered this far.
Issue 3:
This bug happens more and more often the longer the application and operating system has been running. Running into the iPad will give me a number of Errors including "Unable to Connect to Debugger" or "Finished Successfully" among others. But the important part of this issue is that the application will never get sent to the iOS device. It will compile and say it finished. But there will be a error in the output pane.
I hope others have encountered these errors and Hopefully there is a quick fix with config files or something that will make development a lot more convenient. Thanks to anyone for resolution to any of these issues.....
EDIT
I finally received an email from apple support. I have emailed them off a Capture from XCode 4 and will hopefully hear something from them. Or maybe they will just release a new beta. Either way I hope to get this resolved asap.
For issue #2 you might want to try auto-saving your code before runs. See XCODE auto save code when build and run? instructions. Not sure if these instructions will work for 4.2 but you get the idea.
I had issues with my Xcode 4.2 install crashing initially. Re-running the installer over the already installed Xcode 4.2 fixed them. Obviously I don't know what the underlying issue with the install was, but although the first install reported installation was successful, obviously it wasn't. Perhaps worth trying.
When a newer version of Xcode 4.2 becomes available to you (cough), you might want to see whether installing that one fixes the problem. Perhaps given the issues, you should try uninstalling the previous version first rather than installing over the top?
Do you use multiple windows? They are anathema to Xcode 4. If you persist in your heresy, it may corrupt some files, and slow itself down. You will see a lot of beachballing, and it will be in some sort of GC.
You can work around this by deleting a workspace-specific file hidden inside your project. (I will have to look up which one, if this describes your case.)
With the new Beta GM Release they have seemingly fixed the issue with the Hanging.
Thanks for the Answers. Ill +1 anyone who helped but ultimately it was apple that fixed the issue.... For now

Resources