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
This is probably a solution to a different issue, but what happens if you
declare your "should be visible from Objective-C" swift methods as 'dynamic'?
Austin
> On Jun 4, 2016, at 11:55 AM, Jens Alfke via swift-users
> wrote:
>
>
>> On Jun 4, 2016, at 11:29 AM, Kevin
> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users
> wrote:
>
> 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.
I agree; I didn’t
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.
--
> 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
>
> On Jun 3, 2016, at 7:55 PM, Kevin Lundberg via swift-users
> wrote:
>
> swift code in an app target can be accessed from obj-c if it is internal
> or public. However, swift code in a framework target can only be
> accessed from objc if it is public, not internal.