4.4 · @objc, what does not bridge, and error bridging

Swift and Objective-C share a runtime but not a type system. This section is the border crossing: what you must mark, what simply cannot cross, and how errors translate.

Mental model. Swift code is invisible to Objective-C by default. Everything you want ObjC (or the runtime) to see needs an explicit @objc, and only a subset of Swift can be expressed in it.

Exposing Swift to the runtime

The attributes, and what each one changes.

1. What do @objc, @objcMembers, @objc(name), dynamic and @nonobjc each do? 4.4.1 · L2
   @objc makes a declaration visible to the Objective-C runtime: it gets a selector, appears in the generated -Swift.h header, and can be the target of #selector…

What crosses the border

Types that cannot bridge, and how errors become NSError.

1. Which Swift features cannot be seen from Objective-C? 4.4.2 · L3
   An @objc declaration must be expressible in Objective-C’s type system, so anything outside it is rejected or simply left out of the generated header. Not…
2. How do Swift errors and Objective-C NSError translate across the border? 4.4.3 · L3
   Objective-C reports failure with an NSError ** out-parameter and a return value (BOOL or a nullable object). Swift imports such a method as throws: the error…

More in Objective-C & interop

• 4.1 · Message send, selectors, forwarding, isa
• 4.2 · Categories, associated objects, load and initialize
• 4.3 · NSObject, class clusters, copying
• 4.5 · Nullability, lightweight generics, Swift-friendly names
• 4.6 · Method swizzling, and when it is a footgun
• 4.7 · Reading Objective-C, blocks, and manual reference counting
• 4.8 · Mixed-language projects, costs, and migrating a large app
• 4.9 · How Objective-C declarations arrive in Swift
• 4.10 · The runtime up close: introspection, encodings, IMPs and exceptions
• 4.11 · Key-value coding and observing
• 4.12 · What crosses the boundary: inference and concurrency