<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">My apologies if I insinuated that the effort would be small or trivial, that wasn’t my intent.<div class=""><br class=""></div><div class="">The converse situation that you describe, where objc code must also be public in the framework makes sense. I didn’t mind that myself when I was attempting this since this is an internally used framework only, but ideally that should also be resolved. The fact that swift in frameworks has to be public for this to work today is less a problem for me than the discrepancy between target types.</div><div class=""><br class=""></div><div class="">I logged a radar for the swift -> objc case that I described initially as that’s the use case that affects me most: <a href="rdar://26663470" class="">rdar://26663470</a>. </div><div class=""><br class=""></div><div class=""><div class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">--</div><div class="">Kevin Lundberg</div><div class=""><a href="mailto:kevin@klundberg.com" class="">kevin@klundberg.com</a></div></div></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 1:34 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We don't currently have a way to generate <i class="">two</i> headers, one to be used internally and one externally. For methods and properties on existing types, it's safe to write a category manually to be included in your .m files, but classes and protocols don't really have a good answer.</div><div class=""><br class=""></div><div class="">This is very similar to another existing problem, that you can't import implementation-detail things <i class="">into</i> Swift without making them public. However, that problem still needs a lot of design, whereas this one is essentially as simple as "generate two headers". (It's not <i class="">quite</i> that easy because you need one to import the other rather than having them be independent, but it's still a problem where it's known that the solution will work.)</div><div class=""><br class=""></div><div class="">"Simple" or "easy" does not necessarily mean "quick to implement", though, so we have to balance this against other improvements.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2016, at 13:00, Daniel Dunbar via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""><br class="">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?<br class=""><br class=""> - Daniel<br class=""><br class=""><blockquote type="cite" class="">On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">--<br class="">Kevin Lundberg<br class=""><br class="">On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I ran into a major hurdle this week that basically stopped my work in<br class="">its tracks. I've been working on moving a large codebase from an iOS app<br class="">target to a framework target, since we have the same code in multiple<br class="">app targets and it is problematic to have to remember to add new code to<br class="">every single app target when they can all just share a framework.<br class=""></blockquote><br class="">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?<br class=""><br class="">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.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>