Core Data: Solving Ambiguous Type / Redeclaration of Type

Wed, 29 Mar 2017 02:57:05 +0000

I just finished roasting some coffee from Peru. I’ve never had it before, but it got me thinking about my Roaster On the Go “app” as I thought about the context that I could use to show you the solution to the compiler error described in the title. I used this to demonstrate Working with Unwind Segues Programmatically in Swift, but now I’m going to use it to show you how to resolve these errors that can crop up when you’re implementing NSManagedObject subclasses for your Core Data Entities.

Scenario – Adding a data model

The “app” doesn’t currently use Core Data, but for this article, I’ve created a rudimentary data model that includes a single Entity called Product:

Now suppose that I’m ready to implement a subclass of NSManagedObject for the Product Entity.

Doing so right now using Xcode 8’s default settings is going to give me all kinds of issues.

To be clear, I’m using Xcode 8.2 for this scenario.

The error that I’m getting when I attempt to build after creating a subclass of NSManagedObject for the Product Entity is one of the following (depending on how you choose to create the NSManagedObject subclass):

Invalid redeclaration of ‘Product'

‘Product’ is ambiguous for type lookup in this context

or in the compiler output

filename “Product+CoreDataClass.swift” used twice

What’s happening??

This is a conflict with Xcode 8’s auto codegen for NSManagedObject subclasses. In some versions of Xcode 8 (version 8.2, for example), this auto codegen is turned on by default. This can present a problem if you intend to manually create NSManagedObjectSubclasses for your Entities.

Solution

To solve this problem, or to avoid it before it occurs, you essentially need to turn off Xcode 8’s auto code generation feature for NSManagedObject subclasses if you intend to implement your NSManagedObject subclasses manually (my personal preference).

Take a look at the steps below to get your project building again:

1 – Turn off automatic code generation for NSManagedObject subclasses

Open your data model (the .xcdatamodeld file in your project).

Click on each Entity in your data model and in the Data Model Inspector of the Utilities Pane, change the Codegen property from “Class Definition” or “Category/Extension” to “Manual/None”:

2 – Choose module

You also need to tell Xcode where it can look to find a definition for the NSManagedObject subclass that you will implement for this Entity by choosing “Current Product Module” for the Module value:

Save your .xcdatamodeld file.

3 – Clear derived data

Behind the scenes, Xcode creates files and implements Types for the Entities in your data model. It puts them in your derived data folder and automatically traverses this folder to look for Type definitions for Core Data Entities. So in order to get your project building again, you need to get rid of those files that Xcode created automatically.

The “big hammer” for this is to simply clear all of your project’s derived data. To do this, click on the Products menu, hold down the Option key, and click “Clean build folder…”:

Press Option Key -> Clean Build Folder..." width="224" height="321" class="alignnone size-full wp-image-13118" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder.png 224w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/CleanBuildFolder-209x300.png 209w" sizes="(max-width: 224px) 100vw, 224px" />

Alternatively, you could opt to go in and delete the only auto-generated Swift files, but you’ve got to do some digging.

Click on File -> Project Settings:
Project Settings" width="353" height="495" class="alignnone size-full wp-image-13121" srcset="https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1.png 353w, https://www.andrewcbancroft.com/wp-content/uploads/2017/03/ProjectSettings1-214x300.png 214w" sizes="(max-width: 353px) 100vw, 353px" />

Next, click on the arrow next to the path leading to your default derived data folder:

Next, find the folder for your project at the root of your default derived data directory (where you were taken in Finder when you clicked the arrow in Project Settings). Then get ready to dig…

Click Build -> Intermediates -> ProjectName.build -> Debug-iphonesimulator -> ProjectName.build -> DerivedSources -> CoreDataGenerated -> ProjectName

Delete the .swift files in this folder.

4 – Rebuild

After you rebuild, any compiler errors you previously had, related to “ambiguous Type” or “redeclaration of Type” should be resolved!

Resources

Core Data Fundamentals with Swift

Implement NSManagedObject Subclass in Swift

Fri, 18 Jul 2014 04:08:12 +0000

Updated on July 8, 2016 – Xcode 7

My goal with this blog entry is to help get you set up to create NSManagedObject subclasses in Swift for the Entities in your Core Data model.

Example

Let’s look at a fabricated example: Say that you’ve got a Core Data project and you’re creating Entities. For my simple project, I’ll create an Entity called “MyEntity” with an attribute called “myAttribute”.

After you create an NSManagedObject subclass for the Entity and come back to the data model screen to specify the “Class” in the inspector area, you must prefix the name of the class with “YourProjectName.” (don’t forget the dot). Forgetting to do this will lead to run-time errors when you start interacting with instances of your NSManagedObject subclass.

Apple specifies this in their documentation page, but it was a subtle mention at the end of the document and I just happened upon it as I was troubleshooting this:

Swift classes are namespaced—they’re scoped to the module (typically, the project) they are compiled in. To use a Swift subclass of the NSManagedObject class with your Core Data model, prefix the class name in the Class field in the model entity inspector with the name of your module.

Walk-through

Create an Entity

In your .xcdatamodeld file, create an Entity to your liking. In my example, I named the Entity “MyEntity” and I gave it an attribute called “myAttribute” with a data type of String.

Create an NSManagedObject Subclass for that Entity

On the Menu, click Editor, then “Create NSManagedObject Subclass…”

Make sure you choose “Swift” as your language of choice as you click Next through the wizard and Xcode will generate you a file that is appropriate for your Entity. The files it created for me (Xcode 7.1.1) look like this:

Verify NSManagedObject class in the “Data Model Inspector”

Make sure that you have your .xcdatamodeld file selected in the Navigator panel. Then make sure your Utilities panel is visible.

Click the “Data Model Inspector” icon. This will be the last icon in the inspector of Xcode. You should see a section for “Entity” and within this section, two textboxes: one for Name and one for Class. You should also see a drop-down for the Module that the NSManagedObject subclass is found in.

You’ll be verifying the Class and the Module values:

According to the Swift documentation, Swift class namespaces are scoped to the module they’re compiled in (usually the project you’re working in).

To use the NSManagedObject subclass in your project, you just need to verify that the Module setting is set to “Current Product Module”, assuming that the NSManagedObject subclass you’re wiring this Entity to is found in that module. If it’s in another module, you’ll need to adjust the Module value in the inspector appropriately.

Once the Class and Module values are verified (or set), you’ll be able to use this NSManagedObject subclass anywhere in your project.

NSManagedObject Subclass on Andrew Bancroft