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."
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.
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.
Personally, that is a total game changer for me. I have an app idea, to build a custom house management app for my wife and I. I really don't care to put it on the app store and I don't want to pay $99 for a two person app. Now I can make an app that only my wife and I will use.
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).
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...
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.
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.
Did you read what he said? It doesn't matter when on the world he lives because his argument is based on a ratio, and that's invariant.
That people that can drop money on Apple hardware but can't afford $100 per year doesn't make sense, for the obvious reason that Apple hardware costs many times that.
Back when I was at school I developed some iOS apps, and the $100 was huge where I lived. That's literally 1/4 of minimum salary there. I worked the entire summer holiday to afford an old mac mini(which was really crap,but that was the minimum spec which could run Xcode), and then actually had to borrow money to pay the $100 fee. That's why I prefered android from the start - it was just easier to start developing, with much smaller fee and no membership required to actually deploy to Android devices.
> 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.
If you're serious about making an App, then yes, you should spend the $100. You will get it back in the first couple of days if you make a good app.
The $100 is to keep out the shovel ware and crap-- look at all the junk in the store as it is now. Imagine what it would be like if there wasn't that $100 barrier to entry?
> You will get it back in the first couple of days if you make a good app.
Well, there's the rub. Unfortunately, the vast majority of developers just don't make money on the app stores. I'm not going to beat myself up if it doesn't work out - I'm taking this as a long-term learning opportunity.
If one of my apps takes off on Android (as proof that other people find it good - or I'm confident it is good enough), then I'll pay the $100.
When I recently worked on making our installer work on Mac OS X again (it broke a few years ago, and we don't have a lot of demand for Mac OS X, since we build server software), I did so in a VM on my Linux system. It was slow, it was ornery to get it working, but it was free (if we assume a pirated Mac OS X, though I have a purchased box of a slightly older version than the one I was able to install from a prior Hackintosh experiment that I gave up on, since I found I hate Mac OS X through and through).
I would never build for Mac or iOS if I had to buy a Mac. Since I was able to do so effectively for free, Mac support in our software (which is pretty popular with about 3+ million downloads a year) got a lot better. I didn't enjoy it, and I won't be using that VM for anything other than testing Mac OS X support, but it's silly to act like everyone ought to be willing to shell out money to support a platform (especially in our case, where the vast majority of our paying users are running Linux).
"look at all the junk in the store as it is now. Imagine what it would be like if there wasn't that $100 barrier to entry?"
Whatever happened to the argument that the Apple approval process was to protect users from poor quality software?
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 :)
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".
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.)
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!
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 :)
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.
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!
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.
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.
Not sure why this is downvoted. I find it totally appropriate to criticize marketing speak that is masked as technical description.
Regarding Apple, I find it inappropriate (and dishonest) to use the word "advanced", when it is just catching up with a commodity feature. Exceptions are provided by almost every other modern programming language in the world.
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)
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?
I suspect it's useful to visually signal that the call can fail, and make it obvious what's happening; after all, the "throws" annotation is at the target site, not on the caller end.
You need to prefix anything that throws with a "try":
Other than that, it looks exactly like C++ exceptions: Propagation happens along the chain of functions marked as "throws", until a "catch" handler intercepts it.
"try" is an expression, by the way, so you can do things like:
let line = try file.readline()
There's also a "try!" statement that throws a runtime exception if the inner statement throws.
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.
While Swift was designed to interface well with Objective-C and runs on the Objective-C runtime, it is not a wrapper around Objective-C. It was written from the ground up, started by Chris Lattner at Apple.
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. Programs which do care about recovering from exceptions should enable the option."
"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
Agreed, this is an insane requirement. Our app uses commercial libraries from closed source vendors, some of which are no longer distributing newer versions of their libraries. If this becomes a requirement, we will not be able to ship our app because we can't deliver the entire thing in bitcode.
> Our app uses commercial libraries from closed source vendors, some of which are no longer distributing newer versions of their libraries
This is the insane part - you're relying on things you have zero control over and zero support for. Apple's requirement is no different than some fatal bug discovered or backdoor discovered in those libraries - except Apple is giving you some notice without immediately putting the liability on you.
That's not so much of a bitcode problem as a vendor problem. You'd have the same issue when 64bit builds became mandatory, or when uidevice.uniqueIdentifier was banned.
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?
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.
> 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.
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.
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.
You're giving up a lot of performance for that battery life, however, and I think it's probably premature to even think about ARM Macintosh for three years at the least, if ever.
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?
I feel like a lot of basic stuff is broken or non-existent in Xcode. For instance, project text search on my machine freezes up the entire IDE for half an hour, which is ridiculous since A) it's not an unusually large project, and B) it's on an SSD, and it should be running search in a separate thread anyway.. Not to mention last time I used Xcode (6.2) it crashed on me 7 times in the span of an hour on basic things, like unlocking a file. I wish apple would focus on getting the basics right. It sucks because there's not much of an alternative, but it's by far my least favorite IDE to use.
Is your search scope too broad? Too many Pods maybe? I've never had an issue with project text search. The only time I've ever had that many problems in an iOS dev workflow was years ago when I was briefly running OSX through VMWare.
There's something else going on with your environment, it shouldn't be giving you this many problems.
Does xcode use Spotlight for search? I don't think it does. It clearly pounds the disk when searching but as Spotlight is optional and you can choose to not index various locations, relying on Spotlight for search (and being unable to search locations x, y and z) would mean that xcode would not find results in x, y, and z.
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.
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.
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.
I remember having access to Refactoring in an old Objective-C project, but it was far from "refactoring" - it would have been better named "find-and-replace", considering it substituted some occurrences of the word in question in comments, strings, etc, often with incorrect casing.
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.
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.
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!!!)
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.
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.
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.
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.
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.
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...
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.
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.