Monday, June 2, 2014

Thoughts on WWDC 2014: Languar Morghulis

Surprise, Surprise

In my wish list, I put a bunch of things that I thought were unlikely but still hoped for. But the theme of today’s keynote, for me, was things that I had been having problems with for years, but I thought were so far out of the realm of possibility that it didn’t even occur to me to wish for them. Which is not to say that I got everything I wanted–far from it. But many of the things they did announce were genuinely delightful.

Swift

‘Objective-C without the C.’ That’s all they really needed to say.

I, and many others, have been hoping for such a thing for years. In fact, it seemed inevitable: all languages must die, and Objective-C has surely been showing its age. And yet, something that you know must be coming someday is nevertheless surprising when that day suddenly turns out to be… today. In typical Apple fashion, no-one had the slightest clue beforehand. A programming language, developed in secret over years, and unveiled with Apple-level presentational polish and marketing flourish: that has to be a first, right?

I’ve only just barely had a chance to skim the book that Apple published about the language, but so far I like (most) of what I see. Of course, I have some complaints already: some poorly-named keywords (let, func) and questionable whitespace choices in the example code. But there’s a lot to like–for example, the type inference system looks great, a terrific compromise between the desire to avoid writing types all the time, but still having (optional?) compile-time type checking of method parameters. Overall, I like what I see. I’m extremely excited and ready to start writing in this language now.

It’s become an old trope now to contrast Apple with Google, but people are already pointing out Swift’s similarity to Go. I’ve never programmed in Go, so I wouldn’t know. But, just look at the difference in how the two were developed: Google decided to boil the ocean and start with something completely from scratch, free of any ties to all existing platforms. Apple started by taking their existing language, Objective-C, and writing a new compiler for it. Now having expertise in the realm of compiling the language, they looked at what they could do to improve the most common pain points in the syntax and developer tools. Finally, they took that expertise to leave the existing syntax behind, resulting in something with concepts and mechanics that made Objective-C great, but (hopefully) none of the baggage. Swift, rather than being entirely new (although it looks that way on first glance), is simply the latest round in a very long series of iterations. It’s a huge iteration, much larger than anything previously seen from the company, but an iteration just the same.

And the result is the magic feature that will make this all work: Swift seamlessly interoperates with existing Objective-C and C code. Developers don’t have to throw away all of their existing code. They can, from their shiny new Swift code, continue calling and using useful external Objective-C libraries (à la the increasingly-ubiquitous CocoaPods, no doubt). They can dip their feet in, and learn as they go, while continuing to produce useful work the entire time. It’s almost impossible to see how there would be any possibility of widespread developer adoption, were this not the case.

And where to go from here? The biggest question on my mind is whether or not the compiler is going to be open-source. I know it’s built on LLVM, which already is. But just imagine the possibilities: We could be writing in the same language on both iOS and server-side… and maybe even other platforms?

The future’s an exciting place to be.

OS X Adirondacks

Please sit back and relax. For your comfort and convenience, I have translated the product name into another awkward plural.

I’ll confess: last night, I got the fear. I was remembering iOS 7’s launch, and I broke out in a cold sweat. I saw what happened last year, I grumbled to myself as I paced around my living room at midnight, shaking my head and sighing. You guys keep your hands off of my Mac!

But…it’s okay. I looked at it today, and I felt okay. I’m looking at it now, and I still feel okay.

I’m not a designer (a fact that is constantly frustrating). I can’t tell you the right amount of shadows to put on something, or which colours will go right together. The best I can do–and I really try hard at this, to an often absurd degree–is to take a frame of reference, like Apple’s design guidelines…and imitate them as closely as possible. I am a programmer, and I know how to read a spec, and to adhere to that spec like the cruellest, most exacting drill sergeant you’ve ever seen. I can see when a single pixel is off. And I know how to pick up on conventions, when the best apps all come together to agree on rules without ever writing them down or even verbally discussing them, and to replicate those same ideas in my work. But I have absolutely no eye for art; for creating something new and visually-pleasing out of nothing. I never could do it.

What I’m trying to get at is that I can’t tell you why OS X 10.10 looks good or not, and even if I could, you shouldn’t listen to me. But I do know when I look at something whether I like it or not. And, now that I can look at this instead of just worrying about it, I’m not afraid any more.

Also, these smart people seem to agree:

Awesome features. Color. Shadow. Depth. Friendly and not garish. Great work by everyone at Apple who designed Yosemite and made it work.

— Sebastiaan de With (@sdw) June 2, 2014

(The new icons seem to have balance iOS 7 should’ve. Flatter, but still with some texture and life. Shadows, ok. Rich leather, no. Color. 👍)

— Cabel Sasser (@cabel) June 2, 2014

So there you have it.

OS X: It’s going to be okay.™

I am ok with this.

— Steven Frank (@stevenf) June 2, 2014

Everything Everywhere

When I’m working, I use my Mac. When I’m out, I use my iPhone. When I’m home relaxing, I use my iPad. And yet… even inside my home, I carry two devices around with me at all times: the iPhone and the iPad. Just in case I were to receive a phone call or one of those infernal green-bubbled messages. I should really only need one device at a time, but… this is one of those things that it just never occurred to me that Apple would try to solve. Sure, the technology is all there, but it’s just one of those intractable the-way-it’s-always-been type things. So I’m happy that it’s getting solved, even if it wasn’t really a huge deal.

The rest of the Handoff stuff doesn’t sound like it’s solving a problem that I personally have very often, but it makes sense, I suppose.

iCloud Photo Library is so very late in coming that I thought we would never get it, to the extent that I didn’t even put it on my wishlist. But I am glad it’s here. Picturelife (which I currently pay for, though probably not for much longer) just got Sherlocked; it seems photo management startups must be cursed. Anyway, Apple is being extremely cagey about pricing options, and I’m not sure why; the prices shown during the keynote are nowhere to be found on Apple’s web site, as far as I can tell. It looked like you would still only get 5 GB of total iCloud storage for free, which is shared with Photo Library and all other iCloud features. I worry that many users will fill this up very quickly and then refuse to pay anything, unknowingly putting themselves at risk of losing their photos when they lose/break/replace their iPhone. Google, of course, is happy to keep all of your photos forever for free, because Google wants your photos. Apple doesn’t want your photos; they’re doing this as a favour to you, or because they feel like they have to provide this feature in order to remain competitive. This reluctance does not bode well.

And finally, Family Sharing is yet another thing I thought we’d never see. The situation with iTunes purchases has been stuck in impractical metaphor of ‘1 purchase = 1 person = 1 ID’ for so long, and it was surely mired in legal problems courtesy of movie studios and record labels that seemed far beyond Apple’s ability to fix. But here it is, and yet…there’s a worrying disclaimer in the fine print of that page, to the effect that maybe not everything actually can be shared. We’ll just have to see, I guess. Oh, and under the same product banner, are we also replacing Find My Friends? If it makes people less likely to forget that that functionality exists (which, in my experience, everyone does), then I guess it’s a good thing.

Grab Bag

What else did I get?

  • Per-app battery power usage: Yep.
  • Inter-app communication: Yep.
  • T-Mobile Wi-Fi calling: Surprisingly yes!
  • DuckDuckGo in Safari: Even more surprisingly yes! Well… on OS X, anyway. But maybe also iOS?

I’ve seen nothing public either way about a bunch of the other stuff, so it’s possible more info will come out in the coming months. (Of course, I have developer access to the betas, but I’m prohibited from writing about it.)

It seems like there’s a lot of new stuff with iCloud, but I’m not quite sure what to make of it yet. CloudKit in particular is somewhat baffling, as it seems to overlap with parts of Core Data, but is incompatible with Core Data. Is Core Data being deprecated? Or merely the interaction between Core Data and iCloud? Hopefully someone who understands this can write up an explanation, or perhaps I can get a better understanding from a WWDC session. In any case, iCloud still doesn’t have a very good reputation with developers at this point, so it’s difficult to get very excited about it.

I didn’t really expect Apple to do anything about the sad state of App Store games. To the contrary, the very first thing they showed, an introduction video, specifically singled out Candy Crush by name for praise. I don’t know what else to say about this that hasn’t already been said. It’s just really unfortunate that Apple doesn’t seem to recognise this problem.

As for Apple TV, well… there was so much other stuff today. But I haven’t forgotten.

Sunday, June 1, 2014

WWDC 2014 Wish List

iOS 8:

  • Conference calling for FaceTime Audio (more than two people)
  • Separate DND schedule for weekend (vs. weekdays)
  • Offline Apple Maps
  • Which apps are using the most battery power?
  • Inter-app communication (almost any solution would be better than the current state of affairs)
  • Let me see more than 9 icons at a time in a folder (on iPad)
  • Fix lock screen passcode entry. If I tap the digits too quickly, it misses some. Regression since iOS 7.0
  • UISafariViewController
  • UMA/GAN, i.e., Wi-Fi calling (on supporting carriers, e.g. T-Mobile)
  • Let me set DuckDuckGo as my default search in Safari
  • Get rid of Newsstand
  • Do something about push notification spam
  • Do something about the game IAP plague
  • And finally: finish what was left unfinished.

OS X:

  • Just don’t totally ruin it, please. OS X has got a good thing going here. Be careful with those low-contrast pastels and that unreadable text…

Apple TV:

  • Anything. Anything at all. (Besides more unwanted icons cluttering up my home screen.)
  • Crash less?
Sunday, June 1, 2014

David Sparks on iWork Collaboration in the iCloud

David Sparks on iWork Collaboration in the iCloud

I tried using this feature with my coworkers shortly after it became available, last year. I was editing a document in Mac Pages and they were looking at it on the web as we talked on a conference call. Even with only one person editing (me), they still got conflict dialogs every 30 seconds or so and keep reloading the web page just to keep seeing the changes I was making.

I couldn’t believe that Apple had shipped such a broken product. Needless to say, none of my coworkers were interested in trying it again after that. Sounds like it hasn’t gotten any better.

For a pretty great alternative, try Quip. It’s been near-flawless for me, and has clients on web, iOS and Android. (It only does word processing, not spreadsheets.) I’m going to be so sad when they inevitably sell out to Google.

Wednesday, May 28, 2014

Accidental Tech Podcast, episode 66

Accidental Tech Podcast, episode 66

On the App Store’s apparent success (starting at about 1h23m50s):

Marco Arment: If you look at it from the super high-up executive’s point of view, […] every quarter, they can point to some number, like look, here’s how much we’ve paid to developers overall, we’re doing great, we have all these apps on our store, people keep buying them, or people keep putting coins in to candy, whatever, and it’s fine, there’s no problems.

John Siracusa: That metric-based approach, though, is what annoys me the most, because they get up there, and this is what they say. They have these numbers, and say: Here’s how many bajillions of dollars we gave to developers. Here’s how many apps we have in the store. Let me show you this awesome app that is great. If they lay them all out like that, you’re like, the App Store is great. But what they don’t realise is that the awesome app that’s great sells nothing. All that money is from bilking a bunch of whales out of money for in-app purchases for crappy games, and the number of apps in the store is high because there’s millions of keyword-spam, clone, piece-of-crap things. And, those three numbers are big on their own, but together they don’t make an App Store filled with awesome games and developers making a lot of money. And I don’t know if they know that, or if they just look at their metrics, and say: that metric’s good, that metric’s good, that metric’s good, therefore the App Store is good. ‘Cause I think when they see these [apps], like [as Apple:] Look at this app, isn’t this a beautiful app used for medical imaging–? [as self:] That sells like ten copies! No one buys it! Everyone is buying Candy Crush and getting their money sucked out of their pockets, and– [as Apple:] There’s so many apps, look how many billions of apps there are! We have more apps– [as self:] Yeah, they’re all crap, what we’re all complaining about is that we realise those things are so different, and we want there to be a store with lots of good high-quality apps made by developers who get a fair price for them and customers who are satisfied with them. And that is not the App Store that exists. But the individual metrics–the numbers look good. I really wonder whether they are fooled by those numbers, or whether they just bring those numbers out and say, well this makes for good PR, but we know internally there’s a bunch of problems.

Something to think about during the keynote next week.

Thursday, May 22, 2014

Chris DeSalvo on the Danger Hiptop (a.k.a. T-Mobile Sidekick) and what it could do

Chris DeSalvo on the Danger Hiptop (a.k.a. T-Mobile Sidekick) and what it could do

I wish I had had one of these back in the day. I was vaguely aware of their existence, but I had no idea they could do so much.

Friday, May 2, 2014

Well, I didn’t — I wouldn’t think that. I thought, you know, you push a button, it goes right to the other thing.

Well, I didn’t — I wouldn’t think that. I thought, you know, you push a button, it goes right to the other thing.

—Chief justice John Roberts, realizing that texts are routed through a service provider (via maxistentialist)

Friday, May 2, 2014

One person's experiment in trying to opt out of Big Data

One person’s experiment in trying to opt out of Big Data

The author was trying to prevent any company from knowing about her pregnancy:

For example, seven months in, my uncle sent me a Facebook message, congratulating me on my pregnancy. My response was downright rude: I deleted the thread and unfriended him immediately. When I emailed to ask why he did it, he explained, ‘I didn’t put it on your wall.’ Another family member who reached out on Facebook chat a few weeks later exclaimed, ‘I didn’t know that a private message wasn’t private!’

Speaking of user education problems. People have no idea how their data is being used.

Even that doesn’t quite encompass the scope of the problem: it doesn’t even occur to people that their everyday activities as they go about their lives are data. 20 years ago, if you wrote a letter to someone, or called them on the phone, that wasn’t ‘data’. Now it is.

Friday, May 2, 2014

Google Chrome is testing an experimental feature that completely hides the current URL

Google Chrome is testing an experimental feature that completely hides the current URL

There seems to be a certain school of thought that the solution to all UI problems is user education.

Consider: If your computer got infected with malware from opening an email attachment, well, then the problem isn’t that email is fundamentally broken1, it’s that your understanding of email is wrong, and maybe you should learn not to open any email attachments ever. (Except when it’s from someone you know, except not even then because it might not really be that person, so learn to tell the difference already why don’t you?) How many times have you heard something like this from Very Smart Technically Literate People?

Similarly, the majority of people who use a web browser today do not know or care what a URL is2. It is a big ugly thing that they have to avoid in order to get things done, and a reminder that computers sometimes make no sense for no reason, probably because they are made by jerks like that guy down the hall who sneers at me when I ask why the printer isn’t working; but whatever, if I could just get this thing to work and do what I need to do, then I can move on to the really interesting things in my life.

And yet, web developers who believe in Tim Berners-Lee’s dream of the open and infinite web, where everyone in the world can participate equally, seem to think that if we could just reach these people, and show them how URLs really make sense and are beautiful and logical and useful and empowering, then these people would embrace URLs and start contributing to universal human knowledge and linking to everything and we would finally have our utopia3.

I’m not saying this isn’t a good or important dream. Like many ideals, it is as worthwhile to reach for as it is impossible to ever actually get to. But… you can’t force it on people. The URL had its chance. Now it’s time to try something else. If you don’t like what Google is trying, then let’s see your new ideas.


  1. Email is fundamentally broken. ↩︎

  2. Or a web browser, for that matter. ↩︎

  3. Or URLtopia, if you will. I’ll show myself out. ↩︎

Wednesday, March 26, 2014

Slightly better syntax for avoiding retain cycles in blocks

Objective-C programmers who work with blocks are familiar with this Xcode warning: ‘Capturing [some variable] strongly in this block is likely to lead to a retain cycle’. Articles like this one explain the problem pretty well, so I won’t recap it here. The solution is also pretty well-known.

My issue is with the syntax. Since it isn’t possible to reference an existing defined variable weakly, it’s necessary to redefine the variable as __weak outside of the block, before you can reference it inside the block.

__weak FooClass weakFoo = foo;

The ` typeof ()` macro can make this a little less brittle, by saving you the trouble of retyping the class name:

__weak__ typeof__(foo) weakFoo = foo;

But that’s still pretty awful. It’s not just that it’s ugly (although it is–those underscores!), but it feels redundant to type such specific instructions over and over again in order to accomplish the same common task. The more code I have to spend doing the compiler’s busywork, the harder it is for someone reading my code to understand my intent.

So I’ve created the following two compiler macros to try to abstract this away, save myself some typing, and make my intent in the code more clear.

I would love to see Apple make something like this built-in to the compiler. I suspect it would be possible to eliminate the ‘capture’ step entirely and simply use a cast-like syntax such as (weak)foo inside the block.

Wednesday, March 26, 2014

Apple's iOS security document includes details about how iMessage works

Apple’s iOS security document includes details about how iMessage works

Old news by this point (from a month ago), but worth mentioning by way of following up to my previous speculation: [1] [2] [3] [4]

It’s a very straightforward explanation (starting on page 20), and it’s in line with how others suspected or were able to discover that it works. The main point is that Apple intentionally designed a system such that they themselves are unable to read the messages passing through it. You can question whether or not it works as intended, but no other popular messaging service has even attempted this, as far as I know, and that makes it significant.

3 of 47