10 ms·

What's new in Xcode 7

252 points by yconst 11y ago

glhaynes 11y ago
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 11y ago
  They have also merged both iOS and OS X developer programs under the same roof. 99$/y gives you access to both now.
  - vvanders 11y ago
    Does this mean you now need to pay $99/y to develop OSX apps?
    - aaronbrethorst 11y ago
      Only if you want to distribute apps in the Mac App Store. Same as it was yesterday.
      - mmastrac 11y ago
        Or sign apps for others to download without the App Store (also the same).
    - gress 11y ago
      No. Just for access to the Mac App Store, and pre-release tools and OS versions.
      - smackfu 11y ago
        Although the second part of that is pretty important if you are a real software developer, even if you sell outside the app store.
    - donarb 11y ago
      No, you only need to pay if you want to distribute apps through the App Store.
      - lultimouomo 11y ago
        Is that right? As of Mavericks, OS X by default refuses to run applications that are not signed with a 99$/year Apple certificate.
        Jtsummers 11y ago
        You can still run them you just have to go through system preferences to enable them.
        ceejayoz 11y ago
        You can always right-click and select "Open".
        chc 11y ago
        I can do that, but it's not reasonable to expect my users to do so. As it is, indie developers have to choose between paying rent to Apple and having most users unable to open their apps.
        mynameisvlad 11y ago
        I mean, really, you're comparing paying rent with a $100/yr fee (which now allows you to sign apps across their platforms)? Really? I highly doubt most indie developers even have to make that choice. Finding the $100 a year is not the most impossible task in the world, even for a tiny indie developer. Plus, more than a few apps have added instructions on their download pages to show users how to get around Gatekeeper. They can clearly take the Gatekeeper hit, so you probably can too.
        chc 11y ago
        I could afford $100 a month. Affordability is not the point. The point is that Apple will block your app from opening by default unless you pay them a recurring fee, and if not, you must incur additional support burden to teach users how to get around the problem. Yes, lots of apps do post instructions on how to get around it, but lots of apps do all sorts of user-unfriendly things. We Apple users used to make fun of Windows for the endless sea of pointless dialogs its users had to go through. Those apps could take the shitty-UI hit, mine probably could too, but it still sucks. A lot of people are intimidated just looking at instructions like that, and will just give up. I don't know about you, but I feel like that's a pretty terrible first-run experience for my app. I don't feel comfortable charging people for something they might not even be able to run. Would Apple be willing to put their own apps behind that kind of painwall?
    - ascagnel_ 11y ago
      Only if you want to publish in the Mac App Store or use any MAS-specific features (eg iCloud sync).
  - TillE 11y ago
    Oh, that's excellent. I was just contemplating whether I really want to pay $99/year just to be able to sign a little Mac app, but if I can get all the iOS stuff too, I'll probably do it.
  - xirdstl 11y ago
    Maybe this explains the recent bug I experienced where, when attempting to renew my iOS developer program for $99, the system added the Mac developer program to my cart for an additional $99 (which I didn't want).
- vbezhenar 11y ago
  What? It means that anyone can download XCode, any app from github and run it on their devices? That's very nice.
  - sohailk 11y ago
    you could potentially bundle xcode + xctool + github into some sort of adhoc app store, no?
    - 0x0 11y ago
      It will probably have a really short code signing certificate expiration date, so you'll have to rebuild and reinstall all the time. They'll probably notice when 100000 users debug-sign the same app ID too...
      - vbezhenar 11y ago
        Re-signing could be done automatically when you plug your iDevice (unless TTL is really short like 1 hour). App ID, hash could be changed easily as well.
        0x0 11y ago
        If you change the app ID you start over with an empty app data directory, which is a bit of a hassle.
        mynameisvlad 11y ago
        Well I presume the hash wouldn't change in between installs, just from user to user.
- Osmium 11y ago
  > Program membership is not required. Though note that there's a current bug listed that looks like accounts with expired developer memberships currently can't use free provisioning. (For me, this is mildly irritating, because I let my membership lapse a few days ago on a hunch that they'd combine the developer programmes. And then they did, but I can't use the free provisioning, and the re-enrolment form doesn't seem to be working right now either.) Really nice to see this though.
  - vbezhenar 11y ago
    You can try to create a new Apple ID while they fixing the bug.
    - Osmium 11y ago
      Thanks, but I managed to re-enroll via iTunes Connect instead. Though why a $99 developer program costs £79 in the UK I have no idea, I guess it's VAT. Hopefully I'll finally get an app out to justify it this year!
      - Alphasite_ 11y ago
        VAT pretty much covers it completely, sans vat its £66.
- tiernano 11y ago
  wonder will the same work for Mono Develop? Build on Windows or Mac with VS or Mono Develop and deploy to an iPhone with a Mac...
- giarc 11y ago
  I love this. I'm thrifty and haven't paid for a dev account but am deep into an app build. When I show clients, there's a bit of an awkward conversation when I explain that I have to show them on my macbook. If I could demo directly on my phone/tablet that would be amazing. Can't wait to use this feature!
  - laydownlarry 11y ago
    you misspelled cheap
    - giarc 11y ago
      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.
      - s73v3r 11y ago
        And you don't consider showing clients to be "needing it"? If I were a client, I'd be questioning how serious you were.
        giarc 11y ago
        Ya I could see that, however I should note the app is only a part of a bigger picture of products. I've also been developing it for the past 4-5 months but only started showing it to people lately. So perhaps now would be a good time to buy a dev account but I still haven't felt the big need. To each their own.
- serve_yay 11y ago
  I'm sure HN will find a talking point to replace that one :)
- carlosrg 11y ago
  FINALLY. I don't understand why they didn't do it earlier.
- fierycatnet 11y ago
  This is awesome. I might get back into iOS app development. I didn't feel like paying money for prototyping just so I could run it on my own device. Emulator wasn't doing it for me. Time to pickup Swift.
- shurcooL 11y ago
  Color me interested. With this, and https://github.com/rakyll/go2xcode https://github.com/rakyll/go2xcode, I might actually try making some apps to run on my iOS device now.
- downandout 11y ago
  This was the big news IMO. Many would-be developers reside in countries where $99/year is a huge amount of money that cannot be justified until they have a final, working product they are ready to distribute.
  - kybernetyk 11y ago
    Yet those developers somehow can buy a computer for $1000+ and spend an additional $500-$800 on the tablet/phone? :)
    - downandout 11y ago
      No, they can't. You can run mac operating systems on any cheap intel hardware (and in vmware), and you can easily buy used phones/macs on eBay. Google the term Hackintosh or "vmware mac".
      - Tloewald 11y ago
        I'm not sure Apple would go far out of its way to help such users.
    - rattray 11y ago
      Not everyone making iOS apps has Apple hardware. I was just at a React Native meetup in Bangalore where half the audience was on Dells running Ubuntu, trying to install hackintosh VM's so they could use XCode and the emulator. The passion for building things doesn't only strike those with four figures of disposable income, you know :)
    - sangnoir 11y ago
      > Yet those developers somehow can buy a computer for $1000+ and spend an additional $500-$800 on the tablet/phone? :)[1] In a word - Yes. I am a developer from a 3rd world country, and I bought a Mac Mini for $500 (not '$1000+') for the purposes of entering the Apple ecosystem. I'm not going to spend another $500 on an iPhone[2], especially since I'm not sure if it will work out financially. The emulator will have to do (my apoligies to anyone who'll potentially run my apps and encounter bugs I miss because of this). 1. I'm not sure if the smiley is an indicator of sarcasm or not 2. If push comes to shove,I can afford it, but I've already bought the phone I'll use for the next 2-3 years (OnePlus), and I'd rather spend the money on other things - like family.
- WalterGR 11y ago
  Not being a developer for Apple products, what has changed?
  - chc 11y ago
    You used to have to get a $99 developer membership to put apps on your iPhone.
- mcintyre1994 11y ago
  Is this a path to non jailbreak sideloading at least for users with OSX and Xcode7? Not exactly likely to make a splash but interesting move if you can share these projects without too much fuss. More generally, this is an awesome move. Kudos to Apple :)
halayli 11y ago
"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.
- McElroy 11y ago
  While try/catch is what is exposed to us as developers, the underlying implementation could very well be advanced.
- pilif 11y ago
  Advanced compared to what was there in previous releases (basically an Error out parameter that you had to check on your own)
- Joky 11y ago
  Advanced != Exclusive/Innovative/... That said, the spec here is a bit different than C++ exception I believe.
  - Someone 11y ago
    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 that the refactoring tools work fine (for example when one removes that "throws" from the definition of loadData)
    - 72deluxe 11y ago
      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?
      - 11y ago
nathan_f77 11y ago
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.
Entalpi 11y ago
"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 11y ago
  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?
  - terhechte 11y ago
    Along those lines, John S. just tweeted "<whisper>ARM Macs…</whisper>" [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 https://twitter.com/siracusa/status/608029277963972608
    - 0x0 11y ago
      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? (maybe) Super cheap devices? (un-apple-like) Changing archs has been done before but I don't see a rosetta for intel apps running smoothly on arm. Virtualizing windows and linux is another killer app for intel macs that would be missed for some.
zimbatm 11y ago
> 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 11y ago
  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 11y ago
> 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 11y ago
  They just added generics to Obj-C, which is one of the biggest new language features in a long time.
  - pjmlp 11y ago
    I guess that is just required for interoperability with Swift. Generics don't make much sense in Objective-C dynamic model.
    - _frog 11y ago
      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/id1002624212?mt=11 https://itunes.apple.com/us/book/using-swift-cocoa-objective...
      - pjmlp 11y ago
        From the talks today it seems Swift interoperability was indeed the purpose.
ngoldbaum 11y ago
Does anyone know if Xcode 7 will include LLVM OpenMP support?
Fargren 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
  - santaclaus 11y ago
    > but I assumed that was just because Apple hates C++ Chris Lattner is a bit of a C++ head, no? LLVM is a C++ project... With that said, yea, refactoring support in Xcode is a drag.
    - 11y ago
BlackLamb 11y ago
It would be interesting to see, how Apple manages to stop people from Side loading apps.
deleted 11y ago
[deleted]
dep_b 11y ago
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.
Thiz 11y ago
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 11y ago
  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 11y ago
    It's a simulator, not an emulator. There's a big difference.
- 72deluxe 11y ago
  Ouch. 2GB RAM? Sleeping and resuming must be really fast (no large capacity of RAM to save to disk) but daily running must be painful.
- sjwright 11y ago
  You say you can't upgrade the computer, but surely you could throw some extra memory in. You could increase it to 8GB for around US$60 and benefit from a substantial improvement in performance across the board.
- cerberusss 11y ago
  If it's just Swift, perhaps you can try and install the command-line developer tools?
msie 11y ago
Stack Views is really cool! I don't need the full power and complexity of AutoLayout.
- cellularmitosis 11y ago
  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...
arihant 11y ago
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.
- bbrian 11y ago
  I run XCode 6 fine on a 2011 MacBook Air.
- 72deluxe 11y ago
  2012 Macs couldn't run xcode? I'm running a 2008 Mac Pro running Xcode 6 and Yosemite. I have a 2012 MacBook Pro at home running Yosemite and Xcode 6 (but my word is the hard disk in that slow - luck of the draw getting a 5200 Hitachi or a Samsung, eh!!!) Which 2012 Macs can't run Xcode 6?
- equoid 11y ago
  "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 11y ago
    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.
iphonedevpinoy 11y ago
I wonder if it's possible to do ad-hoc testing on Xcode 7 without joining the developer program?

252 points by yconst 11y ago

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 11y ago
They have also merged both iOS and OS X developer programs under the same roof. 99$/y gives you access to both now.
- vvanders 11y ago
  Does this mean you now need to pay $99/y to develop OSX apps?
  - aaronbrethorst 11y ago
    Only if you want to distribute apps in the Mac App Store. Same as it was yesterday.
    - mmastrac 11y ago
      Or sign apps for others to download without the App Store (also the same).
  - gress 11y ago
    No. Just for access to the Mac App Store, and pre-release tools and OS versions.
    - smackfu 11y ago
      Although the second part of that is pretty important if you are a real software developer, even if you sell outside the app store.
  - donarb 11y ago
    No, you only need to pay if you want to distribute apps through the App Store.
    - lultimouomo 11y ago
      Is that right? As of Mavericks, OS X by default refuses to run applications that are not signed with a 99$/year Apple certificate.
      - Jtsummers 11y ago
        You can still run them you just have to go through system preferences to enable them.
      - ceejayoz 11y ago
        You can always right-click and select "Open".
        chc 11y ago
        I can do that, but it's not reasonable to expect my users to do so. As it is, indie developers have to choose between paying rent to Apple and having most users unable to open their apps.
        mynameisvlad 11y ago
        I mean, really, you're comparing paying rent with a $100/yr fee (which now allows you to sign apps across their platforms)? Really? I highly doubt most indie developers even have to make that choice. Finding the $100 a year is not the most impossible task in the world, even for a tiny indie developer. Plus, more than a few apps have added instructions on their download pages to show users how to get around Gatekeeper. They can clearly take the Gatekeeper hit, so you probably can too.
        chc 11y ago
        I could afford $100 a month. Affordability is not the point. The point is that Apple will block your app from opening by default unless you pay them a recurring fee, and if not, you must incur additional support burden to teach users how to get around the problem. Yes, lots of apps do post instructions on how to get around it, but lots of apps do all sorts of user-unfriendly things. We Apple users used to make fun of Windows for the endless sea of pointless dialogs its users had to go through. Those apps could take the shitty-UI hit, mine probably could too, but it still sucks. A lot of people are intimidated just looking at instructions like that, and will just give up. I don't know about you, but I feel like that's a pretty terrible first-run experience for my app. I don't feel comfortable charging people for something they might not even be able to run. Would Apple be willing to put their own apps behind that kind of painwall?
  - ascagnel_ 11y ago
    Only if you want to publish in the Mac App Store or use any MAS-specific features (eg iCloud sync).
- TillE 11y ago
  Oh, that's excellent. I was just contemplating whether I really want to pay $99/year just to be able to sign a little Mac app, but if I can get all the iOS stuff too, I'll probably do it.
- xirdstl 11y ago
  Maybe this explains the recent bug I experienced where, when attempting to renew my iOS developer program for $99, the system added the Mac developer program to my cart for an additional $99 (which I didn't want).
vbezhenar 11y ago
What? It means that anyone can download XCode, any app from github and run it on their devices? That's very nice.
- sohailk 11y ago
  you could potentially bundle xcode + xctool + github into some sort of adhoc app store, no?
  - 0x0 11y ago
    It will probably have a really short code signing certificate expiration date, so you'll have to rebuild and reinstall all the time. They'll probably notice when 100000 users debug-sign the same app ID too...
    - vbezhenar 11y ago
      Re-signing could be done automatically when you plug your iDevice (unless TTL is really short like 1 hour). App ID, hash could be changed easily as well.
      - 0x0 11y ago
        If you change the app ID you start over with an empty app data directory, which is a bit of a hassle.
        mynameisvlad 11y ago
        Well I presume the hash wouldn't change in between installs, just from user to user.
Osmium 11y ago
> Program membership is not required. Though note that there's a current bug listed that looks like accounts with expired developer memberships currently can't use free provisioning. (For me, this is mildly irritating, because I let my membership lapse a few days ago on a hunch that they'd combine the developer programmes. And then they did, but I can't use the free provisioning, and the re-enrolment form doesn't seem to be working right now either.) Really nice to see this though.
- vbezhenar 11y ago
  You can try to create a new Apple ID while they fixing the bug.
  - Osmium 11y ago
    Thanks, but I managed to re-enroll via iTunes Connect instead. Though why a $99 developer program costs £79 in the UK I have no idea, I guess it's VAT. Hopefully I'll finally get an app out to justify it this year!
    - Alphasite_ 11y ago
      VAT pretty much covers it completely, sans vat its £66.
tiernano 11y ago
wonder will the same work for Mono Develop? Build on Windows or Mac with VS or Mono Develop and deploy to an iPhone with a Mac...
giarc 11y ago
I love this. I'm thrifty and haven't paid for a dev account but am deep into an app build. When I show clients, there's a bit of an awkward conversation when I explain that I have to show them on my macbook. If I could demo directly on my phone/tablet that would be amazing. Can't wait to use this feature!
- laydownlarry 11y ago
  you misspelled cheap
  - giarc 11y ago
    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.
    - s73v3r 11y ago
      And you don't consider showing clients to be "needing it"? If I were a client, I'd be questioning how serious you were.
      - giarc 11y ago
        Ya I could see that, however I should note the app is only a part of a bigger picture of products. I've also been developing it for the past 4-5 months but only started showing it to people lately. So perhaps now would be a good time to buy a dev account but I still haven't felt the big need. To each their own.
serve_yay 11y ago
I'm sure HN will find a talking point to replace that one :)
carlosrg 11y ago
FINALLY. I don't understand why they didn't do it earlier.
fierycatnet 11y ago
This is awesome. I might get back into iOS app development. I didn't feel like paying money for prototyping just so I could run it on my own device. Emulator wasn't doing it for me. Time to pickup Swift.
shurcooL 11y ago
Color me interested. With this, and https://github.com/rakyll/go2xcode https://github.com/rakyll/go2xcode, I might actually try making some apps to run on my iOS device now.
downandout 11y ago
This was the big news IMO. Many would-be developers reside in countries where $99/year is a huge amount of money that cannot be justified until they have a final, working product they are ready to distribute.
- kybernetyk 11y ago
  Yet those developers somehow can buy a computer for $1000+ and spend an additional $500-$800 on the tablet/phone? :)
  - downandout 11y ago
    No, they can't. You can run mac operating systems on any cheap intel hardware (and in vmware), and you can easily buy used phones/macs on eBay. Google the term Hackintosh or "vmware mac".
    - Tloewald 11y ago
      I'm not sure Apple would go far out of its way to help such users.
  - rattray 11y ago
    Not everyone making iOS apps has Apple hardware. I was just at a React Native meetup in Bangalore where half the audience was on Dells running Ubuntu, trying to install hackintosh VM's so they could use XCode and the emulator. The passion for building things doesn't only strike those with four figures of disposable income, you know :)
  - sangnoir 11y ago
    > Yet those developers somehow can buy a computer for $1000+ and spend an additional $500-$800 on the tablet/phone? :)[1] In a word - Yes. I am a developer from a 3rd world country, and I bought a Mac Mini for $500 (not '$1000+') for the purposes of entering the Apple ecosystem. I'm not going to spend another $500 on an iPhone[2], especially since I'm not sure if it will work out financially. The emulator will have to do (my apoligies to anyone who'll potentially run my apps and encounter bugs I miss because of this). 1. I'm not sure if the smiley is an indicator of sarcasm or not 2. If push comes to shove,I can afford it, but I've already bought the phone I'll use for the next 2-3 years (OnePlus), and I'd rather spend the money on other things - like family.
WalterGR 11y ago
Not being a developer for Apple products, what has changed?
- chc 11y ago
  You used to have to get a $99 developer membership to put apps on your iPhone.
mcintyre1994 11y ago
Is this a path to non jailbreak sideloading at least for users with OSX and Xcode7? Not exactly likely to make a splash but interesting move if you can share these projects without too much fuss. More generally, this is an awesome move. Kudos to Apple :)

halayli 11y ago

"Advanced error handling model using try / catch / throw that feels natural in Swift." yeah try/catch is very advanced.

McElroy 11y ago
While try/catch is what is exposed to us as developers, the underlying implementation could very well be advanced.
pilif 11y ago
Advanced compared to what was there in previous releases (basically an Error out parameter that you had to check on your own)
Joky 11y ago
Advanced != Exclusive/Innovative/... That said, the spec here is a bit different than C++ exception I believe.
- Someone 11y ago
  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 that the refactoring tools work fine (for example when one removes that "throws" from the definition of loadData)
  - 72deluxe 11y ago
    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?
    - 11y ago

nathan_f77 11y ago

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.

Entalpi 11y ago

"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 11y ago
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?
- terhechte 11y ago
  Along those lines, John S. just tweeted "<whisper>ARM Macs…</whisper>" [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 https://twitter.com/siracusa/status/608029277963972608
  - 0x0 11y ago
    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? (maybe) Super cheap devices? (un-apple-like) Changing archs has been done before but I don't see a rosetta for intel apps running smoothly on arm. Virtualizing windows and linux is another killer app for intel macs that would be missed for some.

zimbatm 11y ago

> 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 11y ago
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 11y ago

> 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 11y ago
They just added generics to Obj-C, which is one of the biggest new language features in a long time.
- pjmlp 11y ago
  I guess that is just required for interoperability with Swift. Generics don't make much sense in Objective-C dynamic model.
  - _frog 11y ago
    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/id1002624212?mt=11 https://itunes.apple.com/us/book/using-swift-cocoa-objective...
    - pjmlp 11y ago
      From the talks today it seems Swift interoperability was indeed the purpose.

ngoldbaum 11y ago

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

Fargren 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.
- santaclaus 11y ago
  > but I assumed that was just because Apple hates C++ Chris Lattner is a bit of a C++ head, no? LLVM is a C++ project... With that said, yea, refactoring support in Xcode is a drag.
  - 11y ago

BlackLamb 11y ago

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

deleted 11y ago

[deleted]

dep_b 11y ago

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.

Thiz 11y ago

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 11y ago
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 11y ago
  It's a simulator, not an emulator. There's a big difference.
72deluxe 11y ago
Ouch. 2GB RAM? Sleeping and resuming must be really fast (no large capacity of RAM to save to disk) but daily running must be painful.
sjwright 11y ago
You say you can't upgrade the computer, but surely you could throw some extra memory in. You could increase it to 8GB for around US$60 and benefit from a substantial improvement in performance across the board.
cerberusss 11y ago
If it's just Swift, perhaps you can try and install the command-line developer tools?

msie 11y ago

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

cellularmitosis 11y ago
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...

arihant 11y ago

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.

bbrian 11y ago
I run XCode 6 fine on a 2011 MacBook Air.
72deluxe 11y ago
2012 Macs couldn't run xcode? I'm running a 2008 Mac Pro running Xcode 6 and Yosemite. I have a 2012 MacBook Pro at home running Yosemite and Xcode 6 (but my word is the hard disk in that slow - luck of the draw getting a 5200 Hitachi or a Samsung, eh!!!) Which 2012 Macs can't run Xcode 6?
equoid 11y ago
"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 11y ago
  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.

iphonedevpinoy 11y ago

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