What's new in Xcode 7

Post by lobster_johnson » Tue, Jun 09, 2015, 7:27 PM UTC

72deluxe wrote: post #151

Someone wrote: post #45

Earlier quoted context omitted.

Agreed. Also, it does look different aka innovative to me: func loadData() throws { } func test() { do { try loadData() } catch { print(error) } } I guess that you have to prefix any statement that might throw with 'try', and cannot prefix other statements with it. If so, their motto really seems to be 'explicit over implicit'. I'm not sure that is an improvement, but I'm not sure that it is bad, either, provided t…

Doesn't that mean typing try a million times instead of putting potentially throwable calls inside one try block and a bunch of different catch handlers? I wonder why they insist on that. Perhaps it is easier to parse?

    func mightThrow() throws {
      try mightAlsoThrow();
    }

    let line = try file.readline()

Post by sjwright » Tue, Jun 09, 2015, 9:07 PM UTC

e28eta wrote: post #132

cellularmitosis wrote: post #121

Earlier quoted context omitted.

Obj-C already had try / catch, it just wasn't considered idiomatic to the platform. Amazon caught a bunch of flak when they wrote an Obj-C interface to AWS and all of the error handling was try/catch instead of NSError (probably, they just line-for-line transliterated their Java interface).

"The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway.…

Post by giarc » Tue, Jun 09, 2015, 9:45 PM UTC

s73v3r wrote: post #130

giarc wrote: post #86

Earlier quoted context omitted.

Sure, cheap/thrifty whatever. However, I'd rather pay for the dev account when I actually need it. I don't see a huge benefit to paying $100/year while in development. I can accomplish everything I want without it. Once I'm ready to publish the app in the app store, I'll gladly pay $100/year.

And you don't consider showing clients to be "needing it"? If I were a client, I'd be questioning how serious you were.

Post by cerberusss » Wed, Jun 10, 2015, 7:03 AM UTC

0x0 wrote: post #51

terhechte wrote: post #46

Earlier quoted context omitted.

Along those lines, John S. just tweeted " ARM Macs… " [1], which is interesting, as he also got the Open Sourcing of Swift right a couple of days ago. [1] https://twitter.com/siracusa/status/608029277963972608

Interesting, although the open sourcing of swift feels more obvious than arm macs. Bitcode and app thinning are currently ios+watchos only. I think it sounds more likely for ios and especially the watch changing architectures in the future rather than a non-x86/64 osx. But I'm probably wrong. What would be the selling points for an ARM MAC? Access to the iOS app store software library? (unlikely) Better battery usage…

Post by pvieito » Sat, Jun 13, 2015, 8:23 PM UTC

mrsteveman1 wrote: post #26

lultimouomo wrote: post #17

Earlier quoted context omitted.

Is that right? As of Mavericks, OS X by default refuses to run applications that are not signed with a 99$/year Apple certificate.

I'll admit that the right-click workaround is a minor speedbump but it does work. And Developer ID certificates are valid much longer than a year, I believe mine expires in 2019. They aren't revoked if you stop paying for program membership, and the expiration applies to the signing operation, apps you've signed in the past will continue to work after the certificate expires.