Re: [swift-users] Trouble with function properties

[Doug Hill via swift-users]

Thank you Saagar for looking over this code for me. I guess I got really caught 
up in the weird diagnostic message and assumed things weren’t working.
Now I see that ‘afunc’ works as I expected:

60> g.afunc(numberRecords:1,userRecord:(13,9))
13 9
$R3: (Int, (Int, Int)) = {
  0 = 13
  1 = {
0 = 9
1 = 1
  }
}

Although I would be interested in why the compiler spits out the first message 
in the first place (e.g. the message with the strange description of afunc).

Looking forward to see what I can do with Swift,

Doug Hill

> On Jun 15, 2016, at 6:49 PM, Saagar Jha  wrote:
> 
> `Gen` defines `afunc`, but you’re trying to access `aFunc`.
> 
> On Wed, Jun 15, 2016 at 6:22 PM Doug Hill via swift-users 
> > wrote:
> I’m just starting to learn Swift and attempting to do some functional-style 
> programming. Specifically I’m learning how to create generic algorithms that 
> can be reused for many different types.
> What I’m attempting to do is create a new object, passing functions to the 
> initializer. The class would store these functions as properties and then use 
> them for functional-style algorithms.
> 
> The problem is I’m running into weird compiler errors/messages that I’m 
> trying to figure out. I'm hoping someone here can give me some pointers on 
> what these errors mean, and most likely what I’m doing wrong.
> 
> Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.31) Target: 
> x86_64-apple-macosx10.9
> 
> // =
> class Gen {
> typealias func1Type = (numberRecords:InputKeyType, userRecord: 
> InputValueType ) -> (OutputKeyType, OutputValueType)
> 
> var afunc: func1Type
> 
> init( inFunc: func1Type ) {
> afunc = inFunc
> }
> }
> 
> var g: Gen =
> Gen( inFunc: { (numberRecords: Int, userRecord: (Int, Int)) -> (Int, 
> (Int, Int)) in
> var b: Int = numberRecords
> var (age, numFriends) = userRecord
> print( (age), (numFriends) )
> return (age, (numFriends, 1))
> }
> )
> // =
> 
> What I get as output from the Swift compiler are these confusing messages. I 
> included some print statements that hopefully gives some more info about 
> what’s happening.
> 
> g: Gen = {
>   afunc = 0x0001012024d0 $__lldb_expr7`partial apply forwarder for 
> reabstraction thunk helper from @callee_owned (@unowned Swift.Int, @unowned 
> Swift.Int, @unowned Swift.Int) -> (@unowned (Swift.Int, (Swift.Int, 
> Swift.Int))) to @callee_owned (@in Swift.Int, @in (Swift.Int, Swift.Int)) -> 
> (@out (Swift.Int, (Swift.Int, Swift.Int))) at repl6.swift
> }
> 
> print( (g) )
> Gen
> 
> print( (g.aFunc) )
> repl.swift:48:9: error: value of type 'Gen' 
> has no member 'aFunc'
> ^ ~
> 
> There’s a good chance I’m doing something wrong but I don’t know how to 
> figure out what that problem is. Any ideas?
> 
> Thanks.
> 
> Doug
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> -- 
> -Saagar Jha

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Binary Size vs. Obj-C

[Seth Friedman via swift-users]

I'm seeing 7.375 MB for Swift 3 dylibs with a Release build, and I don't
have WebKit, XPC, OnoneSupport, IOKit, CoreData, and AppKit in my binary
when I create just a bare bones app.

Thanks,
Seth

On Wed, Jun 15, 2016 at 5:59 PM Marco S Hyman  wrote:

> On Jun 15, 2016, at 5:37 PM, Seth Friedman via swift-users <
> swift-users@swift.org> wrote:
> >
> > Does anyone know if the runtime libs definitively increased in size in
> Swift 3? I could have sworn I heard 4.5 MB for Swift 2.
>
> The total of the Frameworks dir in a Swift 2.2 app I have is 5.8M.  The
> breakdown for this app is:
>
>  64KlibswiftAppKit.dylib
> 4.8MlibswiftCore.dylib
>  44KlibswiftCoreData.dylib
> 112KlibswiftCoreGraphics.dylib
>  32KlibswiftCoreImage.dylib
>  84KlibswiftDarwin.dylib
>  40KlibswiftDispatch.dylib
> 516KlibswiftFoundation.dylib
>  64KlibswiftObjectiveC.dylib
>  48KlibswiftWebKit.dylib
>
> So how big might partially depend upon what frameworks the app uses.  The
> same app in Swift 3 is 6.6M -- a little bit bigger.  It’s breakdown is:
>
>  76KlibswiftAppKit.dylib
> 4.5MlibswiftCore.dylib
>  44KlibswiftCoreData.dylib
> 116KlibswiftCoreGraphics.dylib
>  36KlibswiftCoreImage.dylib
>  68KlibswiftDarwin.dylib
>  40KlibswiftDispatch.dylib
> 552KlibswiftFoundation.dylib
>  36KlibswiftIOKit.dylib
>  64KlibswiftObjectiveC.dylib
> 1.0MlibswiftSwiftOnoneSupport.dylib
>  48KlibswiftWebKit.dylib
>  36KlibswiftXPC.dylib
>
> The Swift 3 version is a debug build, the swift 2.2 version isn’t.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Trouble with function properties

[Saagar Jha via swift-users]

`Gen` defines `afunc`, but you’re trying to access `aFunc`.

On Wed, Jun 15, 2016 at 6:22 PM Doug Hill via swift-users <
swift-users@swift.org> wrote:

> I’m just starting to learn Swift and attempting to do some
> functional-style programming. Specifically I’m learning how to create
> generic algorithms that can be reused for many different types.
> What I’m attempting to do is create a new object, passing functions to the
> initializer. The class would store these functions as properties and then
> use them for functional-style algorithms.
>
> The problem is I’m running into weird compiler errors/messages that I’m
> trying to figure out. I'm hoping someone here can give me some pointers on
> what these errors mean, and most likely what I’m doing wrong.
>
>   Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.31) Target:
> x86_64-apple-macosx10.9
>
> // =
> class Gen {
> typealias func1Type = (numberRecords:InputKeyType, userRecord:
> InputValueType ) -> (OutputKeyType, OutputValueType)
>
> var afunc: func1Type
>
> init( inFunc: func1Type ) {
> afunc = inFunc
> }
> }
>
> var g: Gen =
> Gen( inFunc: { (numberRecords: Int, userRecord: (Int, Int)) -> (Int, (
> Int, Int)) in
> var b: Int = numberRecords
> var (age, numFriends) = userRecord
> print( (age), (numFriends) )
> return (age, (numFriends, 1))
> }
> )
> // =
>
>
> What I get as output from the Swift compiler are these confusing messages.
> I included some print statements that hopefully gives some more info about
> what’s happening.
>
> g: Gen = {
>   afunc = 0x0001012024d0 $__lldb_expr7`partial apply forwarder for
> reabstraction thunk helper from @callee_owned (@unowned Swift.Int, @unowned
> Swift.Int, @unowned Swift.Int) -> (@unowned (Swift.Int, (Swift.Int,
> Swift.Int))) to @callee_owned (@in Swift.Int, @in (Swift.Int, Swift.Int))
> -> (@out (Swift.Int, (Swift.Int, Swift.Int))) at repl6.swift
> }
>
> print( (g) )
> Gen
>
> print( (g.aFunc) )
> repl.swift:48:9: error: value of type 'Gen Int)>' has no member 'aFunc'
> ^ ~
>
>
> There’s a good chance I’m doing something wrong but I don’t know how to
> figure out what that problem is. Any ideas?
>
> Thanks.
>
> Doug
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
-- 
-Saagar Jha
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Trouble with function properties

[Doug Hill via swift-users]

I’m just starting to learn Swift and attempting to do some functional-style 
programming. Specifically I’m learning how to create generic algorithms that 
can be reused for many different types.
What I’m attempting to do is create a new object, passing functions to the 
initializer. The class would store these functions as properties and then use 
them for functional-style algorithms.

The problem is I’m running into weird compiler errors/messages that I’m trying 
to figure out. I'm hoping someone here can give me some pointers on what these 
errors mean, and most likely what I’m doing wrong.

  Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.31) Target: 
x86_64-apple-macosx10.9

// =
class Gen {
typealias func1Type = (numberRecords:InputKeyType, userRecord: 
InputValueType ) -> (OutputKeyType, OutputValueType)

var afunc: func1Type

init( inFunc: func1Type ) {
afunc = inFunc
}
}

var g: Gen =
Gen( inFunc: { (numberRecords: Int, userRecord: (Int, Int)) -> (Int, (Int, 
Int)) in
var b: Int = numberRecords
var (age, numFriends) = userRecord
print( (age), (numFriends) )
return (age, (numFriends, 1))
}
)
// =

What I get as output from the Swift compiler are these confusing messages. I 
included some print statements that hopefully gives some more info about what’s 
happening.

g: Gen = {
  afunc = 0x0001012024d0 $__lldb_expr7`partial apply forwarder for 
reabstraction thunk helper from @callee_owned (@unowned Swift.Int, @unowned 
Swift.Int, @unowned Swift.Int) -> (@unowned (Swift.Int, (Swift.Int, 
Swift.Int))) to @callee_owned (@in Swift.Int, @in (Swift.Int, Swift.Int)) -> 
(@out (Swift.Int, (Swift.Int, Swift.Int))) at repl6.swift
}

print( (g) )
Gen

print( (g.aFunc) )
repl.swift:48:9: error: value of type 'Gen' 
has no member 'aFunc'
^ ~

There’s a good chance I’m doing something wrong but I don’t know how to figure 
out what that problem is. Any ideas?

Thanks.

Doug___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Binary Size vs. Obj-C

[Marco S Hyman via swift-users]

On Jun 15, 2016, at 5:37 PM, Seth Friedman via swift-users 
 wrote:
> 
> Does anyone know if the runtime libs definitively increased in size in Swift 
> 3? I could have sworn I heard 4.5 MB for Swift 2.

The total of the Frameworks dir in a Swift 2.2 app I have is 5.8M.  The 
breakdown for this app is:

 64KlibswiftAppKit.dylib
4.8MlibswiftCore.dylib
 44KlibswiftCoreData.dylib
112KlibswiftCoreGraphics.dylib
 32KlibswiftCoreImage.dylib
 84KlibswiftDarwin.dylib
 40KlibswiftDispatch.dylib
516KlibswiftFoundation.dylib
 64KlibswiftObjectiveC.dylib
 48KlibswiftWebKit.dylib

So how big might partially depend upon what frameworks the app uses.  The same 
app in Swift 3 is 6.6M -- a little bit bigger.  It’s breakdown is:

 76KlibswiftAppKit.dylib
4.5MlibswiftCore.dylib
 44KlibswiftCoreData.dylib
116KlibswiftCoreGraphics.dylib
 36KlibswiftCoreImage.dylib
 68KlibswiftDarwin.dylib
 40KlibswiftDispatch.dylib
552KlibswiftFoundation.dylib
 36KlibswiftIOKit.dylib
 64KlibswiftObjectiveC.dylib
1.0MlibswiftSwiftOnoneSupport.dylib
 48KlibswiftWebKit.dylib
 36KlibswiftXPC.dylib

The Swift 3 version is a debug build, the swift 2.2 version isn’t.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Binary Size vs. Obj-C

[Seth Friedman via swift-users]

Does anyone know if the runtime libs definitively increased in size in
Swift 3? I could have sworn I heard 4.5 MB for Swift 2.

Also, does anyone know if there are plans to introduce a `-Os` equivalent
for Swift? (Yes, I'm using that in Obj-C, to answer your question).

Thanks!

Seth

On Wed, Jun 15, 2016 at 5:27 PM Austin Zheng  wrote:

> Sorry, I totally missed the part where you mentioned the runtime libs.
>
> I assume you're compiling your Objective-C code using the `-Os`
> optimization level? Unfortunately, it doesn't seem like swiftc has any
> flags for trading off speed and binary size. Part of the size discrepancy
> is almost certainly due to the immaturity of the compiler.
>
> This is probably only valid for the roughest of OOM estimates, but
> LinkedIn's iOS app is 135 MB (don't know how it breaks down in terms of
> assets vs code), and is almost entirely implemented in Swift. It's not much
> to go off, but it might provide you with a starting point.
>
> If any of your company's engineers are at WWDC, you might want to have
> them ask the engineers during the developer tools labs.
>
> Best,
> Austin
>
>
> On Wed, Jun 15, 2016 at 5:16 PM, Seth Friedman via swift-users <
> swift-users@swift.org> wrote:
>
>> Thanks for the quick reply. You guys are right on part of it; the runtime
>> libraries are causing the majority of the increase. I thought the Swift
>> runtime libraries were supposed to only take up 4.5 MB though? Did they
>> increase with Swift 3? If I add up all of the libraries, they take up a
>> total of 22.88 MB in the binary. About how big would they be if I had
>> Bitcode turned on?
>>
>> That said, the actual Swift binary is still larger. In my table view
>> example, the Objective-C binary is 144 KB and the Swift binary is 201 KB. 
>> *That's
>> still a 40% increase*. Obviously it's much harder to test a large-scale
>> app, but I'd like to know the percentage increase to expect if we were to
>> migrate to Swift.
>>
>> On Wed, Jun 15, 2016 at 5:04 PM Saagar Jha  wrote:
>>
>>> Yep, I just took a simple app and opened up the ipa. 90% of it is the
>>> “Frameworks” directory containing the Swift frameworks
>>> libSwiftCore.dylib, libSwiftDarwin.dylib, etc.
>>>
>>>
>>> On Wed, Jun 15, 2016 at 3:43 PM Seth Friedman via swift-users <
>>> swift-users@swift.org> wrote:
>>>
 Hi all,

 I've seen a ton of blog posts written about all of the cool and
 exciting things about Swift, but I haven't see anything really about the
 downsides (besides the occasional post about pain points with
 interoperability). What's of biggest concern to me when considering
 migrating my company's app from Objective-C to Swift is binary size. Swift
 binary size seems to be several times larger than Objective-C, and I'm
 curious what data there is in the community to support this suspicion.

 For some quick data points, I created a single view controller project
 in Obj-C and one in Swift, turned off bitcode to get a better idea of what
 the binary size on device would be, and archived them. I did this in Xcode
 8 Beta 1 using Swift 3 so that I'd make sure to get any binary size
 improvements in Swift 3.

 The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I
 know that the Swift runtime libs are about 4.5 MB, but subtracting that,
 the Swift IPA file is still *30x bigger than the Obj-C equivalent*.
 Next, I tried adding a simple table view controller, a Person model with a
 first and last name, and a data source that puts the first and last names
 in the table view in an attempt to make a functioning app. However, the
 binary sizes were about the same (the Obj-C one actually decreased to 635
 KB).

 When we're talking about binary sizes this small, it's not a big deal,
 but my company's app is currently 81 MB, about 35 MB of which is code, and
 the rest is assets. If the code part of the binary size increases by orders
 of magnitude like this, we'll go way over the 100 MB cellular limit that
 Apple has set. This is also a really bad experience for customers in
 emerging markets like China and India that have poor connections.

 Can anyone confirm or deny that Swift binary size is orders of
 magnitude larger than Objective-C? I'm looking for the specific increase
 we'll see to take to my management in order to make a justification for
 whether it's worth it for our customers.

 Thanks!

 Seth Friedman


 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users

>>> --
>>> -Saagar Jha
>>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>

Re: [swift-users] Swift Binary Size vs. Obj-C

[Austin Zheng via swift-users]

Sorry, I totally missed the part where you mentioned the runtime libs.

I assume you're compiling your Objective-C code using the `-Os`
optimization level? Unfortunately, it doesn't seem like swiftc has any
flags for trading off speed and binary size. Part of the size discrepancy
is almost certainly due to the immaturity of the compiler.

This is probably only valid for the roughest of OOM estimates, but
LinkedIn's iOS app is 135 MB (don't know how it breaks down in terms of
assets vs code), and is almost entirely implemented in Swift. It's not much
to go off, but it might provide you with a starting point.

If any of your company's engineers are at WWDC, you might want to have them
ask the engineers during the developer tools labs.

Best,
Austin


On Wed, Jun 15, 2016 at 5:16 PM, Seth Friedman via swift-users <
swift-users@swift.org> wrote:

> Thanks for the quick reply. You guys are right on part of it; the runtime
> libraries are causing the majority of the increase. I thought the Swift
> runtime libraries were supposed to only take up 4.5 MB though? Did they
> increase with Swift 3? If I add up all of the libraries, they take up a
> total of 22.88 MB in the binary. About how big would they be if I had
> Bitcode turned on?
>
> That said, the actual Swift binary is still larger. In my table view
> example, the Objective-C binary is 144 KB and the Swift binary is 201 KB. 
> *That's
> still a 40% increase*. Obviously it's much harder to test a large-scale
> app, but I'd like to know the percentage increase to expect if we were to
> migrate to Swift.
>
> On Wed, Jun 15, 2016 at 5:04 PM Saagar Jha  wrote:
>
>> Yep, I just took a simple app and opened up the ipa. 90% of it is the
>> “Frameworks” directory containing the Swift frameworks libSwiftCore.dylib,
>> libSwiftDarwin.dylib, etc.
>>
>>
>> On Wed, Jun 15, 2016 at 3:43 PM Seth Friedman via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> Hi all,
>>>
>>> I've seen a ton of blog posts written about all of the cool and exciting
>>> things about Swift, but I haven't see anything really about the downsides
>>> (besides the occasional post about pain points with interoperability).
>>> What's of biggest concern to me when considering migrating my company's app
>>> from Objective-C to Swift is binary size. Swift binary size seems to be
>>> several times larger than Objective-C, and I'm curious what data there is
>>> in the community to support this suspicion.
>>>
>>> For some quick data points, I created a single view controller project
>>> in Obj-C and one in Swift, turned off bitcode to get a better idea of what
>>> the binary size on device would be, and archived them. I did this in Xcode
>>> 8 Beta 1 using Swift 3 so that I'd make sure to get any binary size
>>> improvements in Swift 3.
>>>
>>> The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I know
>>> that the Swift runtime libs are about 4.5 MB, but subtracting that, the
>>> Swift IPA file is still *30x bigger than the Obj-C equivalent*. Next, I
>>> tried adding a simple table view controller, a Person model with a first
>>> and last name, and a data source that puts the first and last names in the
>>> table view in an attempt to make a functioning app. However, the binary
>>> sizes were about the same (the Obj-C one actually decreased to 635 KB).
>>>
>>> When we're talking about binary sizes this small, it's not a big deal,
>>> but my company's app is currently 81 MB, about 35 MB of which is code, and
>>> the rest is assets. If the code part of the binary size increases by orders
>>> of magnitude like this, we'll go way over the 100 MB cellular limit that
>>> Apple has set. This is also a really bad experience for customers in
>>> emerging markets like China and India that have poor connections.
>>>
>>> Can anyone confirm or deny that Swift binary size is orders of magnitude
>>> larger than Objective-C? I'm looking for the specific increase we'll see to
>>> take to my management in order to make a justification for whether it's
>>> worth it for our customers.
>>>
>>> Thanks!
>>>
>>> Seth Friedman
>>>
>>>
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>> --
>> -Saagar Jha
>>
>
> ___
> 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

Re: [swift-users] Swift Binary Size vs. Obj-C

[Seth Friedman via swift-users]

Thanks for the quick reply. You guys are right on part of it; the runtime
libraries are causing the majority of the increase. I thought the Swift
runtime libraries were supposed to only take up 4.5 MB though? Did they
increase with Swift 3? If I add up all of the libraries, they take up a
total of 22.88 MB in the binary. About how big would they be if I had
Bitcode turned on?

That said, the actual Swift binary is still larger. In my table view
example, the Objective-C binary is 144 KB and the Swift binary is 201
KB. *That's
still a 40% increase*. Obviously it's much harder to test a large-scale
app, but I'd like to know the percentage increase to expect if we were to
migrate to Swift.

On Wed, Jun 15, 2016 at 5:04 PM Saagar Jha  wrote:

> Yep, I just took a simple app and opened up the ipa. 90% of it is the
> “Frameworks” directory containing the Swift frameworks libSwiftCore.dylib,
> libSwiftDarwin.dylib, etc.
>
>
> On Wed, Jun 15, 2016 at 3:43 PM Seth Friedman via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi all,
>>
>> I've seen a ton of blog posts written about all of the cool and exciting
>> things about Swift, but I haven't see anything really about the downsides
>> (besides the occasional post about pain points with interoperability).
>> What's of biggest concern to me when considering migrating my company's app
>> from Objective-C to Swift is binary size. Swift binary size seems to be
>> several times larger than Objective-C, and I'm curious what data there is
>> in the community to support this suspicion.
>>
>> For some quick data points, I created a single view controller project in
>> Obj-C and one in Swift, turned off bitcode to get a better idea of what the
>> binary size on device would be, and archived them. I did this in Xcode 8
>> Beta 1 using Swift 3 so that I'd make sure to get any binary size
>> improvements in Swift 3.
>>
>> The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I know
>> that the Swift runtime libs are about 4.5 MB, but subtracting that, the
>> Swift IPA file is still *30x bigger than the Obj-C equivalent*. Next, I
>> tried adding a simple table view controller, a Person model with a first
>> and last name, and a data source that puts the first and last names in the
>> table view in an attempt to make a functioning app. However, the binary
>> sizes were about the same (the Obj-C one actually decreased to 635 KB).
>>
>> When we're talking about binary sizes this small, it's not a big deal,
>> but my company's app is currently 81 MB, about 35 MB of which is code, and
>> the rest is assets. If the code part of the binary size increases by orders
>> of magnitude like this, we'll go way over the 100 MB cellular limit that
>> Apple has set. This is also a really bad experience for customers in
>> emerging markets like China and India that have poor connections.
>>
>> Can anyone confirm or deny that Swift binary size is orders of magnitude
>> larger than Objective-C? I'm looking for the specific increase we'll see to
>> take to my management in order to make a justification for whether it's
>> worth it for our customers.
>>
>> Thanks!
>>
>> Seth Friedman
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
> --
> -Saagar Jha
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Binary Size vs. Obj-C

[Saagar Jha via swift-users]

Yep, I just took a simple app and opened up the ipa. 90% of it is the
“Frameworks” directory containing the Swift frameworks libSwiftCore.dylib,
libSwiftDarwin.dylib, etc.


On Wed, Jun 15, 2016 at 3:43 PM Seth Friedman via swift-users <
swift-users@swift.org> wrote:

> Hi all,
>
> I've seen a ton of blog posts written about all of the cool and exciting
> things about Swift, but I haven't see anything really about the downsides
> (besides the occasional post about pain points with interoperability).
> What's of biggest concern to me when considering migrating my company's app
> from Objective-C to Swift is binary size. Swift binary size seems to be
> several times larger than Objective-C, and I'm curious what data there is
> in the community to support this suspicion.
>
> For some quick data points, I created a single view controller project in
> Obj-C and one in Swift, turned off bitcode to get a better idea of what the
> binary size on device would be, and archived them. I did this in Xcode 8
> Beta 1 using Swift 3 so that I'd make sure to get any binary size
> improvements in Swift 3.
>
> The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I know
> that the Swift runtime libs are about 4.5 MB, but subtracting that, the
> Swift IPA file is still *30x bigger than the Obj-C equivalent*. Next, I
> tried adding a simple table view controller, a Person model with a first
> and last name, and a data source that puts the first and last names in the
> table view in an attempt to make a functioning app. However, the binary
> sizes were about the same (the Obj-C one actually decreased to 635 KB).
>
> When we're talking about binary sizes this small, it's not a big deal, but
> my company's app is currently 81 MB, about 35 MB of which is code, and the
> rest is assets. If the code part of the binary size increases by orders of
> magnitude like this, we'll go way over the 100 MB cellular limit that Apple
> has set. This is also a really bad experience for customers in emerging
> markets like China and India that have poor connections.
>
> Can anyone confirm or deny that Swift binary size is orders of magnitude
> larger than Objective-C? I'm looking for the specific increase we'll see to
> take to my management in order to make a justification for whether it's
> worth it for our customers.
>
> Thanks!
>
> Seth Friedman
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
-- 
-Saagar Jha
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Binary Size vs. Obj-C

[Austin Zheng via swift-users]

Swift binaries are so massive currently because there's no ABI stability,
therefore the runtime and support libraries must be packaged with every
application. This should change in the future.

Best,
Austin

On Wed, Jun 15, 2016 at 3:43 PM, Seth Friedman via swift-users <
swift-users@swift.org> wrote:

> Hi all,
>
> I've seen a ton of blog posts written about all of the cool and exciting
> things about Swift, but I haven't see anything really about the downsides
> (besides the occasional post about pain points with interoperability).
> What's of biggest concern to me when considering migrating my company's app
> from Objective-C to Swift is binary size. Swift binary size seems to be
> several times larger than Objective-C, and I'm curious what data there is
> in the community to support this suspicion.
>
> For some quick data points, I created a single view controller project in
> Obj-C and one in Swift, turned off bitcode to get a better idea of what the
> binary size on device would be, and archived them. I did this in Xcode 8
> Beta 1 using Swift 3 so that I'd make sure to get any binary size
> improvements in Swift 3.
>
> The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I know
> that the Swift runtime libs are about 4.5 MB, but subtracting that, the
> Swift IPA file is still *30x bigger than the Obj-C equivalent*. Next, I
> tried adding a simple table view controller, a Person model with a first
> and last name, and a data source that puts the first and last names in the
> table view in an attempt to make a functioning app. However, the binary
> sizes were about the same (the Obj-C one actually decreased to 635 KB).
>
> When we're talking about binary sizes this small, it's not a big deal, but
> my company's app is currently 81 MB, about 35 MB of which is code, and the
> rest is assets. If the code part of the binary size increases by orders of
> magnitude like this, we'll go way over the 100 MB cellular limit that Apple
> has set. This is also a really bad experience for customers in emerging
> markets like China and India that have poor connections.
>
> Can anyone confirm or deny that Swift binary size is orders of magnitude
> larger than Objective-C? I'm looking for the specific increase we'll see to
> take to my management in order to make a justification for whether it's
> worth it for our customers.
>
> Thanks!
>
> Seth Friedman
>
>
>
> ___
> 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

[swift-users] Swift Binary Size vs. Obj-C

[Seth Friedman via swift-users]

Hi all,

I've seen a ton of blog posts written about all of the cool and exciting
things about Swift, but I haven't see anything really about the downsides
(besides the occasional post about pain points with interoperability).
What's of biggest concern to me when considering migrating my company's app
from Objective-C to Swift is binary size. Swift binary size seems to be
several times larger than Objective-C, and I'm curious what data there is
in the community to support this suspicion.

For some quick data points, I created a single view controller project in
Obj-C and one in Swift, turned off bitcode to get a better idea of what the
binary size on device would be, and archived them. I did this in Xcode 8
Beta 1 using Swift 3 so that I'd make sure to get any binary size
improvements in Swift 3.

The Obj-C IPA file was 639 KB. The Swift IPA file was *23.6 MB*. I know
that the Swift runtime libs are about 4.5 MB, but subtracting that, the
Swift IPA file is still *30x bigger than the Obj-C equivalent*. Next, I
tried adding a simple table view controller, a Person model with a first
and last name, and a data source that puts the first and last names in the
table view in an attempt to make a functioning app. However, the binary
sizes were about the same (the Obj-C one actually decreased to 635 KB).

When we're talking about binary sizes this small, it's not a big deal, but
my company's app is currently 81 MB, about 35 MB of which is code, and the
rest is assets. If the code part of the binary size increases by orders of
magnitude like this, we'll go way over the 100 MB cellular limit that Apple
has set. This is also a really bad experience for customers in emerging
markets like China and India that have poor connections.

Can anyone confirm or deny that Swift binary size is orders of magnitude
larger than Objective-C? I'm looking for the specific increase we'll see to
take to my management in order to make a justification for whether it's
worth it for our customers.

Thanks!

Seth Friedman
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Feedback for Dependency Injection Framework?

[Ian Terrell via swift-users]

Hi Mike,

Thanks for the library. It looks like you've done a lot of great hacking on
it:

Dependency injection is a topic near and dear to me. :) I'm very curious
about this pattern and its libraries and have been investigating them more
deeply lately. I haven't yet seen the value in this approach (not just in
Swift, but in any language), but if you have time and interest I'd be very
happy to learn your thoughts (and others') on why it's superior to manual
dependency injection. I wouldn't normally do this :), but I'm responding to
your invitation:

Even would be stoked with a response to the tune of "You don't need DI in
> Swift for reasons X, Y, and Z."


As an aside, I tried to peek at your example app

to get more context (it's linked at the bottom of the "Satisfying
Dependencies" section of your README), but it appears missing.

My first point of confusion is that these libraries seem to be less about
dependency injection and more about service location. For instance, in your
GitHub example in the playground, we see the following:

struct GithubListMembersServiceImpl : GithubListMembersService {
> let githubURL: TaggedProvider


>
func listMembers(organizationName: String, handler: [String] -> ()) {
> let url = githubURL
> .get()
>
> .URLByAppendingPathComponent("orgs/\(organizationName)/public_members")
> let dataTask = urlSession.dataTaskWithURL(url) ...


To my mind it doesn't look like githubURL was injected. It looks like it
was looked up in a service locator. In fact, it appears that the Binder is
a service locator, and you can simply set up multiple service locators for
multiple environments (with the added flexibility of multiple types via
tags). I call this solving the problem of inflexible global state (usually
singletons) by making it a flexible global state (a global service locator).

I've always thought of dependency injection as being a tool for avoiding
global state. But in this case it seems to me like the service locator is
globally managed. The language of service locators is even present in
Guice's excellent motivation page
 (my emphasis):

Guice will inspect the annotated constructor, and *lookup* values for each
> parameter.
>

Another point I've heard people talk about is that these libraries help as
dependencies grow. I hope this isn't a straw man, as I interpret the
following line in your README in that way.

As the functionality of this app grows, one may add arguments to
> RootViewController and its dependencies as well as more modules to satisfy
> them.
>

The argument seems to go that this is easy to maintain:

init(a: A)


But this is difficult:

init(a: A, b: B, c: C, d: D, e: E, ...)


The argument goes further by saying that it becomes especially difficult as
you may need to pass the dependencies through the some nodes of the object
graph that seem not to need them. For instance, in the object graph A -> B
-> C, if C has a dependency on Foo but B does not, why should B know about
Foo?

But I find that argument unconvincing on two grounds. First, I believe an
object's dependencies are the union of its and its children's dependencies.
In the example above, B has an implicit dependency on Foo. "Skipping"
passing them around or instantiating them in the owning class is actually
only hiding an object's true dependencies by using global state. Second, as
a single object's dependencies become more unwieldy it seems in practice to
indicate an architectural problem where objects are doing too much. These
problems are related, as the architectural problem may not be as visible
when the true dependencies are hidden!

So to me — and with great respect for the work you've done! I know a lot of
people (even some of my teammates with Dagger) value this approach
immensely — I don't personally see how the approach adds value over manual
injection, and I think the complexity is a negative.

I do think there is value in aiding with property injection for the cases
where we can't use initializer injection (we do often use storyboards at my
company, although we try to keep them small and unwieldy!), but I think
those cases are solved with a few clever extensions. See post-script if
you're curious.

So: I'd love to know what sorts of use cases you find where this sort of
library is very helpful.

Thanks,
Ian

For contrast, I've been handling property injection on iOS with a few
helpers, depending on how I want to do it.

For segues identified by identifier (at my company we do tend to use
storyboards with medium frequency; although we keep them separated into
small collections of scenes rather than large unwieldy ones), extensions
help create code like this:

let dependency: Dependency   // itself injected, or

// var dependency: Dependency! // if it could not be injected at
> instantiation



override func 

[swift-users] Swift Meetup

[Emo Abadjiev via swift-users]

Hello,

We are organising Swift meetup  in
Sofia and interested to find out more about:

   - can we use the Swift logo? Where we can get a vector image, if yes.
   - is there a good place to register as a new community


Thanks,
Emo Abadjiev
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users