Consider the following Cocoa project structure: Host |-- LoadablePlugIn | |-- Main.storyboard | |-- Info.plist | |-- TDWLPIClassOne.h | |-- TDWLPIClassOne.m | |-- TDWLPIClassTwo.h | |-- TDWLPIClassTwo.m |-- TDWAppDelegate.h |-- TDWAppDelegate.h |-- TDWClassOne.h |-- TDWClassOne.m |-- TDWUtils.h |-- TDWUtils.mm |-- Base.lproj | `-- Main.storyboard |-- Info.plist `-- main.m Here the root folder refers to sources of the Host target (the main executable target), while LoadablePlugIn refers to resources of an embedded plug-in target with corresponding name. Both targets at the same time want to use TDWUtils symbols for their own purposes, so I add TDWUtils.mm to compile sources of both Host and LoadablePlugIn targets. It compiles and works without issues, however since the LoadablePlugIn is supposed to load during run-time the linker is not able to locate duplicated symbols of TDWUtils.mm in the binaries and I’m not sure if that is a robust scenario: ... Class plugInPrincipalClass = [NSBundle bundleWithURL:loadablePlugInURL].principalClass; NSWindowController *windowController = [plugInPC instantiateInitialController]; ... Should I compile LoadablePlugIn with hidden symbols compiler flag (like -fvisibility=hidden) or use any other technique to prevent the name collision or can I just leave it as is because in both binaries the symbols of TDWUtils have exactly the same implementation?

Consider the following Objective-C protocol declaration, which requires only class methods: @protocol TDWMethoding<NSObject> + (void)foo; + (void)bar; @end Assuming I need to return an instance of a Class which conforms to this protocol from a method, how am I supposed to specify the return type? - (nullable /*return-type*/)instantiateMethoding { Class instance = ... // some implementation if ([instance conformsToProtocol:@protocol(TDWMethoding)]) { return instance; } return nil; } There are a number of working options I considered so far in regards to how to express the /*return-type*/, but each has its own downsides: Class - this way it doesn't expose conformance. What kind of Class is it? What does it do? Does it conform to the protocol at all? Class<TDWMethoding> - this looks like a viable solution and even was suggested a few times by other developers (here and here) but I personally find it inconsistent and misleading: when we have a variable of form Type<Protocol> *instance, it commonly means that protocol class methods should be sent to the instance's class ([[instance class] foo]) not the instance itself ([instance foo]); id<TDWMethoding> and returning an instance of the class instead - this is consistent, but it requires me to instantiate the class, which is both redundant and prevents me from hiding the constructors of the utility classes which conforms to the protocol with NS_UNAVAILABLE macro. Is there a better semantic to express such a return-type?

There are quite a few features a C function acquires when defined inside of the @implementation block of an Objective-C class, e.g. it can be accessed before declared: @implementation TDWClass - (void)method { bar(); // the function is accessible here despite not being declared in the code before } void bar(void) { NSLog(@"Test"); } @end Plus it is granted access to the private ivars of the class: @implementation TDWClass { @private int _var; } - (void)foo { bar(self); } void bar(TDWClass *self) { self->_var += 2; // a private instance variable accessed } @end Some sources also say that static variables inside of @implementantion section had special meaning (unlike C static they were private to the enclosing class, not the compilation unit), however I could not reproduce this on my end. Having that said, almost all such features were either deduced or found on third-party sources. I wonder if anything like that is/had ever been documented anywhere, so i can read through full list or special meanings of C statements inside of Objective-C class sections?

Consider the following Objective-C class: @interface TDWClass : NSObject - (void)Method; @end If I include this in the bridging header, and try to invoke the Method from Swift its name is changed from the UpperCamelCase to just camelCase: TDWClass().Method() // error "'Method()' has been renamed to 'method()'" I agree that UpperCamelCase for method naming is inconsistent, however I can't see why it is crucial to the extent where the generated code mismatch the original name. Are UpperCamelCase names reserved for some API/System methods? Is there a risk of clashing with some other entities names? I can define such a method name manually in Swift just fine, so the compiler definitely can put up with it. Is there a better rationale than just "it doesn't comply naming guidelines"?

If I remember correctly, back in the days Xcode used to generate the main function something like this (at least for iOS applications): int main(int argc, char * argv[]) { @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]); } } I.e. UIApplicationMain function was wrapped inside of @autoreleasepool. However I noticed that currently Xcode no longer does that: int main(int argc, char * argv[]) { NSString * appDelegateClassName; @autoreleasepool { // Setup code that might create autoreleased objects goes here. appDelegateClassName = NSStringFromClass([AppDelegate class]); } return UIApplicationMain(argc, argv, nil, appDelegateClassName); } So, UIApplicationMain is outside of the autorelease pool by default nowadays. Is there any official changelog/paper that explains why the latter implementation is now preferred over the former one?