Our application target swift code is internal since we don't bother putting public in there as its not shared outside the app(s), obviously. The internally scoped swift code is exported to obj/c through the generated -Swift.h header when in the app target, in addition to anything marked as public (unlike the framework case where only public symbols are found in that header).
This discrepancy seems off, and could possibly trip up anyone else who wants to migrate some mixed language code from an app to a framework. I'd love for there to be some way to import internal symbols in a private/project visible header in objc code in the same framework. I'd be less enthusiastic if consistency went in the other direction where swift code had to be public to be seen in objc code in an app too, but at least that would be consistent behavior for all types of build targets (and if that change resulted in a migrator to do the work that was too much for me to tackle manually, that wouldn't be too bad). -- Kevin Lundberg > On Jun 4, 2016, at 4:00 PM, Daniel Dunbar <daniel_dun...@apple.com> wrote: > > Unfortunately, this is a limitation of the current model for mixed Obj-C and > Swift targets. The Swift code is compiled and optimized as a single module, > and the only supported external entry points that result from that are the > public API, which is then exposed as the "<module>-Swift.h" header file. > > However, this limitation applies to application targets as well, so I'm not > sure I understand yet what the blocker is w.r.t. your migration. Can you > explain more? > > - Daniel > >> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users >> <swift-users@swift.org> wrote: >> >> The former case is what I'm concerned with. I agree that code external to >> the framework should only see public symbols. However objc code inside the >> same framework as the swift code in question should ideally be able to see >> internal swift symbols as well, as they are within the same module. >> >> -- >> Kevin Lundberg >> >> On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon <br...@architechies.com> >> wrote: >> >>>> I ran into a major hurdle this week that basically stopped my work in >>>> its tracks. I've been working on moving a large codebase from an iOS app >>>> target to a framework target, since we have the same code in multiple >>>> app targets and it is problematic to have to remember to add new code to >>>> every single app target when they can all just share a framework. >>> >>> To be clear: Are you having trouble making the Objective-C and Swift inside >>> your framework talk to each other, or the Objective-C outside your >>> framework talk to the Swift inside your framework? >>> >>> If it's the latter, then I agree with Jens that this is "works as >>> intended", and you're just going to have to spend some time pasting >>> `public` into your code in a lot of places. But if you're being forced to >>> make Swift APIs public so you can use them from Objective-C *inside* the >>> framework, that might be something worth talking about. >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users > _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
