
What's new in Xcode 7 - yconst
https://developer.apple.com/xcode/
======
glhaynes
Unexpected: "Xcode 7 and Swift now make it easier for everyone to build apps
and run them directly on their Apple devices. Simply sign in with your Apple
ID, and turn your idea into an app that you can touch on your iPad, iPhone, or
Apple Watch. Download Xcode 7 beta and try it yourself today. Program
membership is not required."

~~~
asendra
They have also merged both iOS and OS X developer programs under the same
roof. 99$/y gives you access to both now.

~~~
vvanders
Does this mean you now need to pay $99/y to develop OSX apps?

~~~
donarb
No, you only need to pay if you want to distribute apps through the App Store.

~~~
lultimouomo
Is that right?

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

~~~
mrsteveman1
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.

~~~
pvieito
So technically, changing the time settings, you could continue signing code
forever?

------
halayli
"Advanced error handling model using try / catch / throw that feels natural in
Swift."

yeah try/catch is very advanced.

~~~
smtddr
You have to understand though, Swift is like a really nice wrapper around
Objective-C. Imagine adding try/catch to C programming language? I know python
& java and all of today's relevant high-level languages have it since forever,
but implementing that in something that wasn't designed for it from the start
is a big task. I'm by no stretch of the imagination an Apple fanatic but as a
person who is about to send out their first mobile app, which happens to be
for iOS, I acknowledge the difficulty of adding try/catch to Swift... and by
extension any Obj-C or plain C used in that same XCode project.

~~~
cellularmitosis
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).

~~~
e28eta
"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. Programs which do care about recovering from
exceptions should enable the option."

[http://clang.llvm.org/docs/AutomaticReferenceCounting.html#e...](http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions)

~~~
sjwright
ARC was short lived and is deprecated.

~~~
cerberusss
Am I missing something? ARC is the default when you start any ObjC-based Xcode
project. It's not deprecated.

------
Entalpi
"Xcode 7 has a ENABLE_BITCODE option to embed bitcode in apps, app extensions,
and frameworks. The option is turned on by default for iOS and is mandatory
for watchOS projects submitted to the store.

When bitcode is enabled for a target, all the objects, static libraries and
user frameworks used when linking that target must contain bitcode. Otherwise,
an error or a warning will be issued by the linker. (Note: missing bitcode is
currently a warning for iOS, but it will become an error in an upcoming beta
release of Xcode 7.) ENABLE_BITCODE should be consistently turned on for all
the targets. If you use a library or framework provided by a third party,
please contact the vendor for an updated version which contains bitcode."

Dear God, do we need to wait for all libs to update? :S

~~~
0x0
Wow, that's quite a change! Is this some kind of intermediate LLVM language?
Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet
you can even change from ARM to x86 then!), but you're handing a lot of
control and probably something much closer to the original source code over to
Apple.

Is there a fundamental change of architecture planned for future iOS devices?

~~~
Someone
[http://llvm.org/docs/BitCodeFormat.html](http://llvm.org/docs/BitCodeFormat.html).
Way closer to assembly than Java/.NET byte codes. Also potentially processor
specific.

My guess is that it is future-proofing towards running iOS apps on Mac OS
and/or running (parts of) iOS apps on the Apple Watch. It also might mean that
Apple plans to make their own ARM extensions (for example, I suspect having
the CPU know about tagged pointers, so that an 'add' instruction can do an
indirection, if needed, might be an overall win)

Update: the release notes for the Xcode 7 Beta say:

 _" • Bitcode. Archive for upload to the App Store in an intermediate LLVM
binary representation that the store can then optimize into the 64 or 32-bit
executable to be delivered to customers."_

This falls under a feature they call 'App Thinning'. It makes the App Store
optimize an app for the device it gets installed on, CPU-wise and asset-wise,
and also allows your app to download some resources on demand.

~~~
grrowl
> also allows your app to download some resources on demand.

Oh boy; if this is the start of apps lazy-loading resources and code, I'm
really excited. It's the largest barrier to signing in your account from any
device.

~~~
coob
There's new higher level stuff for downloading assets on the fly from the App
Store, check out the new NSBundleResourceRequest class.

------
Fargren
Not even a mention of refactoring tools for Swift? Right now you can't even do
a Rename. This was one of the biggest reasons I bought Appcode, actually. And
I'm still waiting for either IDE to implement Extract Method.

It boggles my mind how little I hear people complain about this. Aren't these
basic tools by now?

~~~
nothis
Wait, you can't auto-rename stuff? I noticed in an older version of XCode
(when I still bothered), that there were really basic refactoring tools
missing for C++, but I assumed that was just because Apple hates C++. Apple
obviously doesn't hate Swift.

I guess Apple just hates refactoring. Why though?

~~~
donarb
Most likely Apple is still working out the internals of the Swift compiler.
Refactoring requires a thorough knowledge of code paths and object lifetimes.

Once Swift 2 is nailed down, I'm sure refactoring will follow.

~~~
Fargren
Even in Objective-C, the refactorings available are pretty limited and don't
always work. You can do Rename and Extract Method. In a few corner cases,
Extract method will break. Forget about extracting a variable or a parameter,
of pulling a mtehod up toa superclass. Also, the fact that you have Rename but
you can't find usages for a variable of method seems to me jsut lazy or ill-
thought.

It is a very odd feeling to miss Eclipse, but back when I worked in XCode,
that would frequently be how I felt.

------
dep_b
Am I the only one excited about nil flags and generics support in Objective-C?
I think it's really nice to have an NSArray full of MyObjects that is type
checked compile time.

------
arihant
Every year the new XCode comes, and I'm less excited about new features and
more worried about how many more Macs will I have to buy. Last update on XCode
6 made it impossible for some 2012 models to run it.

This update is almost surely for Yosemite and above. The cost of developing on
Apple platform is crazy these days. I miss the days when they could mock
Microsoft for having an expensive Visual Studio. Now they make you buy a new
Mac per developer every 2 years.

~~~
equoid
"Last update on XCode 6 made it impossible for some 2012 models to run it"

I find this difficult to believe, care to provide evidence of it being an
Apple problem?

~~~
arihant
Macbook Air 2012 models with 4GB soldered RAM ran fine on Mavericks and XCode
6, until Apple decided the newest XCode 6 to be Yosemite only. Now Yosemite is
free, but is absolute abonimation on 2/4GB machines. On top of that, you have
to run XCode. Not to mention the _time debt_ required to upgrade.

Now, for indie developer setting, these issues might not be huge. But the
problem here is - Apple puts _businesses_ in awkward positions, when they have
to bulk buy RAMs and upgrade all the systems just to _compile_ on the newest
minor release of iOS. Then, they started soldering RAM, so now to compile on
8.3, buy 25 new Macs or fuck off.

Apple's actions that screws us - solder RAM, make only latest XCode work with
latest SDK, make OS impossible to run on low RAM, make XCode run only on
newest OS.

~~~
jtd514
Well that is just stupid, the macbook air is not a dev machine. Get a macbook
pro or an imac and you are fine. Apple did not screw you, you screwed yourself
for buying the cheapest they had to offer.

------
zimbatm
> A migrator in Xcode 7 to convert your existing your existing Swift code to
> use the new Swift 2.0 features and syntax.

woops, repetition !

~~~
cellularmitosis
Chris seemed to indicate that this migrator will also somehow handle the
migration from NSError-style error handling to the new try/catch. I'm very
curious to see how sophisticated that will be.

------
pjmlp
> Swift is a successor to both the C and Objective-C languages.

This says it all, regarding what the future for Objective-C looks like.

~~~
anon1385
They just added generics to Obj-C, which is one of the biggest new language
features in a long time.

~~~
pjmlp
I guess that is just required for interoperability with Swift.

Generics don't make much sense in Objective-C dynamic model.

~~~
_frog
Funny you should mention that. Quoting Apple's own docs:

> Objective-C lightweight generics are ignored by Swift. Any other types using
> lightweight generics are imported into Swift as if they were
> unparameterized.[1]

So it doesn't look like the goal here is Swift interop.

[1]: Excerpt from Using Swift with Cocoa and Objective-C (Swift 2 Prerelease)
[https://itunes.apple.com/us/book/using-swift-cocoa-
objective...](https://itunes.apple.com/us/book/using-swift-cocoa-
objective/id1002624212?mt=11)

~~~
pjmlp
From the talks today it seems Swift interoperability was indeed the purpose.

------
nathan_f77
I'm really excited about code coverage, and the built-in user interface
testing support. That's amazing. We currently write our acceptance tests with
KIF, but this sounds so much better. Looking forward to playing with the
automated test recording.

------
msie
Stack Views is really cool! I don't need the full power and complexity of
AutoLayout.

~~~
cellularmitosis
I saw them as being more of a replacement for UITableView for the cases where
you don't need all of its dynamism (cell re-use, etc), and whipping together
half a dozen static table cells involves too much ceremony. In fact I was
hoping I'd be able to use Stack Views to get in the ballpark and then do final
tweaking with AutoLayout...

------
Thiz
Can I use it on my old mac mini 2011 with 2gb ram and Mavericks?

I really want to start using Swift. And no, can't upgrade.

~~~
slm_HN
I doubt it. The last version of XCode 6 won't run without Yosemite, so I'm
guessing 7 will require Yosemite.

Also it's very hard to run with 2gb ram. For example you won't be able to use
the iOS emulator because the swapping will take so long XCode will timeout
when trying to launch the emulator. It's very painful even with 4gb. 8 is
probably the minimum.

~~~
donarb
It's a simulator, not an emulator. There's a big difference.

------
iphonedevpinoy
I wonder if it's possible to do ad-hoc testing on Xcode 7 without joining the
developer program?

------
BlackLamb
It would be interesting to see, how Apple manages to stop people from Side
loading apps.

------
ngoldbaum
Does anyone know if Xcode 7 will include LLVM OpenMP support?

