I'm running the ARC conversion tool for the first time. I've followed the instructions and dealt with all of the issues/erros in my files that the conversion tool finds before it will actually run. I also have several third party libraries that I've told ARC to skip by unchecking them in the Targets to Convert dialog. After running the tool it shows me a report of all the changed files but no files have been changed. Next I save and try to build the project only to find that I have nearly 1000 build errors due to all the calls to retain and release in my project. It's my understanding that the conversion tool is supposed to remove all calls to retain, release, and autorelease but that isn't the case for me.
Has anybody encountered this problem before and if so how did you solve it? Or is it my responsibility to remove all retains & releases from my app? If so I'm not sure what the point of the conversion tool is. Please advise.
Thanks in advance
I am about to try this on my own rather large project, so I may be back with more questions, but I found this that might help:
http://meandmark.com/blog/2011/11/xcode-4-2-convert-to-arc-troubleshooting/
Are you using GIT repositories for your code? It may not be converting due to the snapshot issue described.
This works better in case you allow it to continue building if errors encountered (Preferences - General). However, not all files are changed or converted completely anyway. But a few regulars will do the dirty job.
In case anyone wants to copy and paste;
\[([\[\w\s\]]+) autorelease\]
Related
I installed pod JSQMessagesViewControllerin my Swift project but now I don't need it any more. I do not want to remove it to cause any side effect. Is it alright if I just leave it there and do nothing? Thanks!
Yes, it won't hurt anything. However, it will make the binary larger than it should be due to unused libraries. Also can be confusing later for others looking at the code why a particular library is there. But, the app will not break because of this.
If you aren't making any reference to this framework it shouldn't cause any side effect if you remove it. I really recommend you to remove anything that is no longer used. It's a good practice to avoid problems with future iOS versions when building your project and also makes your app lighter for users with a quicker download.
Just go ahead and remove the pod.
If you truly do not use it, your project will run without problems.
If you do actually use it without knowing about it, your app will most probably not compile, which is a great time to either remove the reference to the pod, or re-add it if you realize that you actually are using it.
If you do actually use it without knowing about it, your app may compile (e.g. if you refer to it from a xib or a storyboard), but will crash when trying to use the non-existing pod. This is much better than keeping on using the pod without knowing that it affects your project.
Good luck!
I've searched around and can't find anything on this.
Using Swift 2 and Xcode Version 7.0.1 (7A1001). Every time I execute something in the debugger console, Xcode crashes.
The project is not very big, and has less than 10 third party frameworks.
I can't think of much more information that's relevant, but I'm sure there's more, so please do ask me if there's anything I should add to my question that would help.
I've of course cleaned build and derived data.
It's driving me insane. Thanks!
UPDATE 16/11/12
Submitted rdar://23559366.
How are you maintaining your third party frameworks? Via Carthage?
If so then this is probably your issue: https://github.com/Carthage/Carthage/issues/924
This is an issue if the location of the /Carthage/Build/iOS folder is in a different location to where it was produced (i.e if it was compiled on a different machine and the absolute file path has changed).
A temporary fix would be to run carthage build --no-use-binaries on your machine to rebuild the symbols using the current absolute file path working around the bug.
But if you wasn't using carthage then its probably not your issue so sorry
I had similar problem with Xcode whenever I hit breakpoint.
In case you see this screen right before your Xcode crashes - you are lucky and my fix might save you. All you need to do is open this window and in the Project Navigator, select any file that you want, so that instead of that white blank view you would get your code. After this you are most likely will be able to successfully stop your app at your breakpoint and perform the debug.
I am not sure why this happens, but I suspect that the reason is Debug View Hierarchy mode, which you might have triggered prior to setting you breakpoint and trying to stop at it. At least this is when it happens to me.
I have similar problem earlier.
If you try to print non-optional variable and unfortunately it holds nil value then it breaks/crash. so that make sure declare all possible variables as "Optional type".
i have this problem for a while now. I have iPhone project which was built with non ARC. And now somehow i need to add another smaller project to it, but that project was built with ARC. I have tried to copy files one by one, but ass soon as i was done, i got lots of ARC errors and some with Security.framework... Can someone help me? Or give me some ideas how should i proceed?
I have tried this but it didnt solvet issius with ARC...
ARC is done at compile time. ARC-enabled source code files need to be compiled with ARC, non-ARC source files need to be compiled without. It is a s simple as that. ARC is nothing but syntactic sugar injected by the compiler.
I have had this problem with some third parties not entirely migrated to ARC. Just create a static library around these files.
You could also try to change the per-file compiler options (see this question: How to disable ARC for a single file in Xcode 5?), but I would recommend against it since it will just become a maintenance burden in the end.
And of course, if it is your source code and not some third party: Migrate it to ARC. It is worth it.
I'm having a severe problem using the new versions of Xcode (4.4 & 4.5) in that, my project has a very large .sql database file stored in the project. This file cannot change, for many reasons... but it is +270Mb in size. This causes Xcode to hang on 'Indexing File...' and becomes completely slow and unresponsive to the point that I have to force quit the app, and cannot actually get any coding done. I have raised a bug report with Apple several times, but it is seemingly being ignored!
I do not want to disable Xcode indexing entirely as i find the code completion features incredibly useful.
My question is: Can i remove the database from the Xcode bundle resources, and then add it automatically at compile time?
Would appreciate any and all advice on how I could get round this problem.
Regards,
Sam
Incase anyone comes across this problem of Xcode indexing a huge unwanted file... I fixed it by setting the file type in Xcode to an 'MP3 Audio file'...
Doesn't seem to have any effect on the function of the .sql file once it's in the App, but stops Xcode trying to index it.
If anyone has a better solution for this, i'd love to hear it!
I'm trying to use Time Profiler, I've used it before.
I'm hiding system libraries, but all of my symbol names are HEX.
I'm running in debug, I have debugSymbols turned on....
I've restarted everything a few times and cleaned everything in between..
... anybody got any other ideas?
it's a bit of a pain because there are a number of variables that can cause this. some of the more common ones are:
sometimes you need to tell instruments where to find your files and/or symbols (Preferences->Search Paths).
have you enabled Link Time Optimization (LTO)? it should be off.
sometimes it helps if you do a clean/build.
sometimes it helps if you restart instruments.
in earlier versions of Xcode, it helped to use a central build directory.
verify that you are generating the proper level of debug symbols for all targets.
I no longer get this problem with the latest version.
Apple were no help in answering this for me - even though I used one of my Tech Support Requests. Must have had them stumped too.