Re: [swift-users] Static linking

2016-06-20 Thread David Beck via swift-users
This morning I used the DYLD_PRINT_STATISTICS environment variable that was recommended in the session (I couldn’t get it to work on an iOS device, so these are numbers from the simulator). “Cold” refers to launching the app after a restart to make sure that the libraries aren’t already in memor

Re: [swift-users] Static linking

2016-06-18 Thread Rod Brown via swift-users
Sorry, by light I was referring to the work required to process these dylibs. Not the actual size of them. From what I know they’re not directionally proportional. > On 18 Jun 2016, at 3:14 PM, Marco S Hyman wrote: > > >> On Jun 18, 2016, at 2:55 PM, Rod Brown via swift-users >> wrote: >>

Re: [swift-users] Static linking

2016-06-18 Thread Marco S Hyman via swift-users
> On Jun 18, 2016, at 2:55 PM, Rod Brown via swift-users > wrote: > > From what I understand, these dylibs are very light Not always so light as earlier discussed on this list. An Xcode 8 Swift 3 compile shows swift Frameworks taking 9.2 MB of the 11.5 MB total app size for an OS X app I’

Re: [swift-users] Static linking

2016-06-18 Thread Rod Brown via swift-users
In regards to Mac and iOS apps, the dylibs are included because of the lack of ABI stability, which was a goal for Swift 3 that was pushed back due to the really significant changes that occurred in the language. >From what I understand, these dylibs are very light and simply act as binding >be

[swift-users] Static linking

2016-06-18 Thread David Beck via swift-users
In session 406: optimizing app startup time at WWDC, most of the recommendations were very pro Swift. Things like using structs and the fact that it can automatically inline calls. One recommendation that was very anti swift, was the section on limiting dylibs. The presenter recommended keeping