Thank you for confirming my suspicions. I know that Bundle won’t help. What I 
was hoping for was a Swift runtime call that returned the current module name. 
Since (at least by convention), there is a correspondence between module names 
and framework names, I was hoping to derive a bundle name from that 
correspondence. But unfortunately, I can’t find a runtime call that helps, 

I’ve thought about other strategies, but since I actually want to put
extensionString {
func locate() -> String {}
in one framework and reference it in other frameworks, this looks to be 
impossibly tricky. (I haven’t tried it, but I expect that if I tried, for 
example, to parse out the module name from inside the locate() function, I’d 
get the name of the module it is located in, not the module of the call-site.) 

 I guess I should file a suggestion radar about it.


Rick Aurbach

On Dec 1, 2016, at 6:36 PM, Jens Alfke 
<<>> wrote:

Introspecting the call stack is possible, if somewhat ugly, using the backtrace 
and backtrace_symbols functions (on macOS/iOS.) But all you get is a list of PC 
and stack addresses, or function names. I don’t know how you’d go from those to 
an NSBundle object. On cursory inspection I didn’t see any NSBundle methods for 
finding out where in memory the associated code is loaded.



Cocoa-dev mailing list (

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)

Help/Unsubscribe/Update your Subscription:

This email sent to

Reply via email to