prehkugler

The file revision history is - to the best of my knowledge - an OS X API that applications have to use (opt in). I don't think it comes "for free" with an OS upgrade, unless you mean Time Machine.

> I see five levels of paranoia: ... 5. Apple, complicit with the NSA, added it.

While it seems possible that Apple conspired with the NSA to add a security hole in SecureTransport, I doubt it. According to sources in the article, this bug was introduced in iOS6; and I haven't heard a mention of it until yesterday, despite it being open-sourced (http://opensource.apple.com/source/Security/Security-55471/l...).

Since nobody was raging on the internet about this bug, I see it as a good-faith effort by Apple to fix a bug that they've just discovered.

If you purchased this with a credit card, you may be able to use the card's warranty. Many credit cards come with an extended warranty service and dispute resolution/fraud protection as a customer incentive (in addition to their points/frequent flier miles/whatever). Even if this is not covered under your card's extended warranty, talking with your credit card company may allow you get the charges reversed.

And here I am, just trying to find notched Dvorak replacement key caps for my MacBook Pro...

I subscribe to this and NSHipster. What other Obj-C resources do you follow?

Just yesterday, my colleagues were describing having Stockholm syndrome with Java. Went something like: "It's really easy to make fun of, but the more you use it, the more you start to feel bad for it."

Not included in the poll is MUMPS. I had a job right out of college that required me to write all of my code in it. It was pretty much the worst thing ever.

As I've already gone to WWDC, would there be any benefit to going?

As an iOS developer, I always enjoy @Horse_iOS.

I agree. The phrases consistently end in a way that is never completely resolved. See:

"In less than three weeks you can be looking at things differently, more creatively, if you"

"Why many people achieve very little despite spending most of their time"

"The interviews can be shorter since you would have many"

This seems like a possible win for Apple, and I hope they implement it. I just wanted to point out that OSX to iOS AirDrop is not as trivial as many people make it sound. There are edge cases, such as "what if the user doesn't have an app that supports this file?". It's different than email, because the file can't be saved in anyone's sandbox.

An interesting perspective. John Gruber does a much better job at refuting it here (under "Defining Innovation Down") than I ever could: http://daringfireball.net/2013/09/the_iphone_5s_and_5c

They don't know anything about it. But a lot of new APIs were made available to developers that will make great apps easier to make. I think that's better for users than a new OS toy.

It's important to ask yourself what you would do if you could AirDrop from your iOS device to an OS X device. Even though under the covers iOS and OS X work on files, iOS is sandboxed where OS X isn't, i.e. if you can't get to it via USB, you couldn't get to it via AirDrop anyway.

With that said, it would be useful to have some of the iTunes/iPhoto functionality for wireless(AirDrop) a la carte file transfer, but most people will just use iTunes wifi sync to get this effect.

It probably would've been useful to know before iOS7 app submissions were open, but, if that's their reasoning, it's a chicken-egg problem.

I think it's prudent to note that Apple made specific guarantees of fingerprint privacy; however such explicit guarantees haven't been made for passcode privacy.

It's iOS 7 for text!

Seriously though, it would be interesting to see this as a feature in new e-readers. I have a feeling that if the e-ink could support it, the effect could be better than books.

As a mobile developer who has worked on both platforms, I agree wholeheartedly with this. Xcode and Interface Builder is much easier to use than Eclipse (I found myself constantly editing the raw XML interface files). And I find the UIKit API much simpler to use (for most cases) than Android's Activity-based SDK.

> So for them, unless a whole category of device comes out, like a smart watch for example, they do not need to have every device to test.

Cue the Samsung Galaxy Gear.

For a minute, I thought you were trying to make a joke about how KitKats are meant to be broken apart.

That game was the main reason I got a DS.

Seems like everyone is discussing "wow, there is a report; it's from Facebook, so it can't be true" instead of "wow the US govt has made ~5x requests of the next-largest requestor."

Edit: see Cowen's comment on contents of the report.

This is going to get pretty darn confusing for people running iOS7 Safari. http://imgur.com/Mv8lu1J

Screen-casting from the desktop version of Google Chrome is a (beta) browser extension. From 2 mins of Googling (I'm no expert), it looks like you can detect those trivially.

Native app download at google.com/chromecast/setup - looks like the native app searches for the devices and uses your computer as an external (wifi?) input for setup.

google.com/chromecast/setup gives you a link to download a native computer app. Looks like it does some wifi search from the native app to "pair" and setup the device.

> Apple TV lets you do the same thing with AirPlay, and it works great.

Not entirely. AirPlay is baked into the OS, so devs don't need to do extra work to support it. Chromecast (or, the Google Cast SDK) is built into the app level, and works in a fundamentally different way (i.e. streams from the internet and allows multi-user queueing vs. streams from the audio/video output of the device).

I don't think it's terribly disruptive - it's essentially AirPlay 2.0 - but it is new.