I have an Iphone app that used the excellent ABContactHelper library origionally written for by Erica Sedun and released on github
Now with the release of XCode4 and Reference Counting support, it causes lots of errors. I have looked at the forks on github, but none seem to have updated to XCode 4 with Reference Counting. I am trying to update it myself but its slow and error prone. I have tried the automatic refactoring support, but to no avail.
Does anyone know of an alternative AddressBook wrapper that provides a simple interface for interacting with the IPhone AddressBook?
In your ARC-enabled project, you can selectively disable ARC for the AddressBook wrapper files by setting the -fno-objc-arc compiler flag for those files.
Add compiler flags in Targets -> Build Phases -> Compile Sources. Enter the compiler flag by double-clicking on the right column of the row under Compiler Flags.
Dealing with ARC/non-ARC issues is a pain in the butt, and I've found that letting CocoaPods handle these problems for me is the way to go. Simply list ABContactHelper as a pod dependency and you're done. Many of the most popular libraries are already there, but if yours isn't, it's really easy to add it.
http://cocoapods.org
Related
I'm exploring Swift with Xcode-6 and so far so good although I think the new collections need a little bit of work as I've managed to break the compiler a few times.
Problem is I'm now stuck trying to create the framework package to then use in another project. The project builds without issue and all tests pass successfully. When I go to create Archive (which I assume is what is required) I receive the error:
:0: error: underlying Objective-C module 'Sample' not found
Now I assume this has something to do with the contents of my Sample.h which tells me
// In this header, you should import all the public headers of your framework using statements like #import <Sample/PublicHeader.h>
which is fine except I have only used swift enums, structs and classes for this framework so therefore no .h files exist.
Can anyone shed some light on this one as I can't find any documentation available yet?
EDIT (7/27/2018)
The information in the answer below may no longer be accurate. Your mileage may vary.
I sat down with an engineer and asked this exact question. This was their response:
Xcode 6 does not support building distributable Swift frameworks at this time and that Apple likely won't build this functionality into Xcode until its advantageous for them to do so. Right now, Frameworks are meant to be embedded in your app's project, rather than distributed. If you watch any of the session videos or see the sample projects, this is always the arrangement. Another reason is that Swift is very new and likely to change. Thus your Swift-based framework is not guaranteed to work on the platform you originally built it on.
Slight Update
The engineer mentioned that it's not impossible to make a framework for distribution, just that it's not supported.
I was able to get past the error by going to the target for the framework and on the Build Phases tab under Headers, remove the MyFramework.h file
However I was getting the "Underlying Objective-C module not found" error when I was using a framework to share code between a containing app and an app extension, both of which were pure Swift.
Assuming you are creating a truly pure Swift module, you must disable the Objective-C Compatibility Header and any generated interface headers so the compiler doesn't go off assuming it can find an Objective-C module for the framework.
Do Not remove your public framework header. You'll get a module-map warning at link time if you do.
You might find this useful: Creation of pure swift module
In short: it's possible to make static framework, but there is one issue: it doesn't work in end user' project if "ProjectName-Swift.h" header included.
But, it works fine if you use only swift.
I think it's a bug in XCode 6, or that Apple does not allow archiving the Framework from XCode while in beta.
If you compile to profile XCode generates the framework correctly. (See the Release folder created in DerivedData)
I'm new to iOS and trying to use RestKit.
I'm getting a 'sigabrt' exception during Singleton instantiation dealing with the use of autoRelease.
I noticed that RestKit uses memory management keywords that are not allowed in iOS projects w/ Automatic Reference Counting (ARC) enabled, could this be an issue?
Anyone encountered anything similar?
I'm surprised you were able to get the project to compile with those keywords.
You will need to use the linker flag -fno-objc-arc in the Compile Sources section of your Build Settings for all RestKit files, or include it as a project that does not use ARC (a much better approach).
Refer to the RestKit installation docs for help on this: https://github.com/RestKit/RestKit/wiki/Installing-RestKit-in-Xcode-4.x . Installing as a git submodule is the way to go imho.
You can easily add the library to a project that use automatic reference counting (ARC) by following the steps below.
Add the Rest kit files to your project.
Go to your project settings, select your application's target(s) and click the "Build Phases" tab.
Expand the section named "Compile Sources".
Select all the files from the RestKit library
Hit Enter to edit all the files at once, and in the floating text-box add the -fno-objc-arc compiler flag.
Thanks.
OK - found the problem: it seems the '-ObjC -all_load' key disappeared, I thoroughly followed RestKit's install instructions but this seemed to have slipped somehow - jshin thanks for making me look through the installation help again :)
Coming from .NET world I have to say XCode/ObjectiveC feel extremely archaic in comparison, just adding a library is a 10 page manual and not to mention the exception that made no sense what's so ever or gave any useful info - but then again this is coming from someone who's new to iOS :)
When i created my project, i made it to support ARC, so my project will support iOS 4.3 and above.
Now i need to integrate Twitter and Facebook to it. Both Facebook and Twitter frameworks given by the companies does not support ARC.
Most of the files have dealloc, and released its variables. Some say to scrap the project and redo it disabling ARC. But, i can't afford to do this, since i have done most of the stuff.
I added the FBConnect files (there were 4 of them) and added -fno-objc-arc as described in this tutorial. Still i get
file://localhost/Users/illepmorgan/Documents/Projects/illep/untitled%20folder/alphaproject/alphaproject/FBRequest.m: error: Automatic Reference Counting Issue: Existing ivar '_delegate' for unsafe_unretained property 'delegate' must be __unsafe_unretained
I need help, i can't redo this again.
Make sure that you added the -fno-objc-arc flag to each implementation file (.m file).
And then clean the project (Project menu -> clean) and build again. I have sometimes had to clean and build twice when doing this in class. Seems like a little bug.
there is actually a much easy way working in mixed ARC and Facebook none ARC .
see my post on how to use it
http://nabtech.wordpress.com/2012/02/02/facebook-ios-sdk-and-arc/
Within several projects, I am using 3rd party code that produce more than a few compiler warnings. I obviously do not want to go through and modify code of actively updated 3rd party projects.
This leaves me with a lot of unnecessary warnings that drown out warnings in MY code.
I have used some compiler flags to suppress specific warnings on a per file basis, but that is much too tedious for open source code with 10-20 .m files.
Is there a way all warnings by Xcode group or file path? Or does somebody have a better suggestion?
(FYI: I am using the LLVM 1.5 compiler)
In my experience, XCode 3.x seems to only show the warnings for files that have actually been compiled in the most recent build, so if you build the project, modify a single file and then build the project again, you'll only see the warnings for the modified file. I generally find this to do more harm than good (especially since in Objective-C it's only a warning to call a selector that doesn't exist!) — and thankfully it's fixed in XCode 4 — but in your case in might be useful.
However, for various reasons you might want to consider putting the third-party code into a Framework. This wouldn't automatically suppress the warnings (although it might make it easier to suppress them) but it would mean that the third-party code was compiled into a library and therefore wasn't part of your normal compile cycle.
Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.
Open the Project Navigator in Xcode
Click on the Project icon at the very top of the navigator
In the resulting detail pane select the target that you are working
with
Select “Build Phases”
Expand “Compile Sources”
In the list locate the file that you’re interested in
Double click the column under the “Compiler Flags” column next to
your file
Add a -w to the resulting dialog
Click “Done”
Build your now warnings free project
here is the reference link
http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
This is certainly not the easier solution, but you could go through these third-party libraries and fix their warning-causing bugs and submit patches. Then, the warnings go away, the bugs are fixed, and everybody gets to enjoy both improvements.
(How many warnings you'll be able to squash this way will depend on what they are: Deprecated-API warnings may be unavoidable if the library needs to support an older version of Mac OS X or iOS where the now-deprecated APIs were the only way.)
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.