Archive for June 22, 2015

Monday, June 22, 2015

Swift Protocols Question

Brent Simmons:

The essence of the best answers was this: Value should not be Equatable — the individual structs should be Equatable.

[…]

In the end, I’m still tempted to say the Objective-C version was simpler. And it is, and not just because I’m more familiar with Objective-C. But it’s important to note that it’s not apples-to-apples. In Objective-C I’m creating classes instead of structs, and there’s no support for the == operator.

But I will say this: Objective-C, because it’s less strict with types, is closer to a scripting language than Swift is.

[…]

Though Swift does get rid of a bunch of housekeeping — we can use type inference much of the time, we don’t have to create .h files, etc. — it adds its own housekeeping mandated by a stricter type system (and optionals).

Eleven Stupid Backup Strategies

Joe Kissell:

Do you use Google Docs, Office 365, iWork for iCloud, or any of a zillion other such Web apps to create and collaborate on documents? Most of us do, at least occasionally. Fine, but do you also have a local copy of those documents? I’ll bet you don’t, and that’s a bad idea.

Other New Swift 2 Features

Paul Hudson:

When a method runs, you want to be sure that it has all the data it needs to work properly, and your code should only execute when that’s the case. Coders solved that in common two ways: pyramids of doom and early returns.

Eric Cerney:

Using guard solves all 3 of the issues mentioned above:

  1. Checking for the condition you do want, not the one you don’t. This again is similar to an assert. If the condition is not met, guard‘s else statement is run, which breaks out of the function.
  2. If the condition passes, the optional variable here is automatically unwrapped for you within the scope that the guard statement was called – in this case, the fooGuard(_:) function. This is an important, yet notably strange feature that really makes the guard statement useful.
  3. You are checking for bad cases early, making your function more readable and easier to maintain.

Paul Hudson:

In Swift 2, Apple introduced API availability checking. If you set your app’s Deployment Target to a lower iOS release than the base SDK, Xcode will automatically scan every API you use to make sure it’s available in your lowest deployment target version. This information has been in Apple’s API headers for years, but it’s only now being exposed to the compiler. What it means is that if your app compiles, you can be guaranteed it doesn’t call any code that can’t run because of missing APIs.

[…]

In that code, #available is going to check whether we’re on iOS 9 or later, or any other unknown platforms like watchOS – that’s the * at the end, and it’s required. And that’s it: all the code you’ll put in place of "// use UIStackView" effectively has elevated rights to use iOS 9.0-only technology, whether that’s classes, methods or enums.

Finally.

Natasha Murashev on unwrapping multiple optionals using pattern matching:

I was at first frustrated by the use of ? to indicate that the value does exist (especially since I associate it with the idea of optionals, where the value may or may not exist), but I have to admit that this example is very clear to understand. And I definitely like it as a much better alternative to the clunky .Some(username) syntax.

Chris Eidhof:

Inspired by Mike Ash’s tweet, I tried generating JSON dictionaries in Swift by using the new reflection features.

[…]

We can provide a default implementation by extending the protocol. This default implementation reflects a value, and loops over the children, recursively serializing them as well. If the type doesn’t have any children, we assume it’s a primitive (e.g. a String or an Int) and don’t serialize it.

Mike Ash:

The terrible world of CFunctionPointer is gone in Swift 2. Instead, Swift function types have trifurcated into variants. Any Swift function type can optionally be annotated with a @convention specifier which says what kind of function it is. The swift convention is the default and indicates a normal Swift function. The block convention indicates an Objective-C block type. These were automatically bridged, and still are, but now the typing is more explicit. Finally, the c convention indicates a C function pointer. Function types annotated with @convention(c) still behave mostly normally, so you can call them and pass them as usual.

Natasha Murashev:

The idea behind for…in filtering is that now you can do filters inline vs in your for loop.

[…]

Note that you can use the pattern matching with “if case” in combination with the for…in filtering for some even more advanced filtering!

I’d still like to see list and dictionary comprehensions.

WebAssembly

Brendan Eich:

In an HN sub-thread sparked by my ModernWeb.tw slides, I concurred with Patrick Walton on analogies between browsers and the Unix kernel, JS and C. One does not get to write kernel code in any language, at least not yet. Elsewhere in that sub-thread the analogue of JS was identified as architecture-specific assembly code, where the CPU architecture is fixed by physical reality, while software is written in virtual languages compiled to machine code, or run through interpreters.

In any event, whether analogous to C or assembly, JS has had a lock on the “kernel” of the client side. Web “userland code”, in contrast, can be written in a great many languages. Adding a second (bytecode) syntax has looked like a “now you have two problems” loss, against the alternative of one syntax. Until now.

It’s by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let’s say. Today I’m pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.

Luke Wagner:

I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web. As reflected in the high-level goals, a central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version run efficiently on current browsers using a client-side polyfill. As demonstrated, the polyfill can leverage asm.js to get great performance. For existing Emscripten/asm.js users, targeting WebAssembly will be as easy as flipping a flag. Thus, it is natural to view WebAssembly as the next evolutionary step of asm.js (a step many have requested and anticipated).

Taylor Swift vs. Apple Music

Taylor Swift:

I write this to explain why I’ll be holding back my album, 1989, from the new streaming service, Apple Music.

[…]

I’m sure you are aware that Apple Music will be offering a free 3 month trial to anyone who signs up for the service. I’m not sure you know that Apple Music will not be paying writers, producers, or artists for those three months.

[…]

This is not about me. Thankfully I am on my fifth album and can support myself, my band, crew, and entire management team by playing live shows. This is about the new artist or band that has just released their first single and will not be paid for its success. This is about the young songwriter who just got his or her first cut and thought that the royalties from that would get them out of debt.

[…]

These are the echoed sentiments of every artist, writer and producer in my social circles who are afraid to speak up publicly because we admire and respect Apple so much.

John Gruber:

Also raises the question of just how many other top-shelf music will not be available on Apple Music when it launches. After the WWDC keynote, I simply could not get a straight answer from anyone at Apple about just how much of the iTunes Music library will be available on Apple Music when it launches. Part of that might be that they’re still negotiating with some labels and top-shelf acts, but I can’t help but suspect part of it is that they know they’re not going to have everything, and they don’t want to talk about that.

Peter Kafka (via John Gruber):

In the U.S., Apple will pay music owners 71.5 percent of Apple Music’s subscription revenue. Outside the U.S., the number will fluctuate, but will average around 73 percent, he told Re/code in an interview.

[…]

Apple won’t pay music owners anything for the songs that are streamed during Apple Music’s three-month trial period, a bone of contention with music labels during negotiations for the new service. But Kondrk says Apple’s payouts are a few percentage points higher than the industry standard, in part to account for the lengthy trial period; most paid subscription services offer a free one-month trial.

Nick Lockwood:

It seems to me with iTunes & App Store, Apple created an incredible opportunity for content creators to be paid fairly, only to squander it.

iTunes raised the price of MP3s from free (pirate) to 99c, likewise the App Store created a way to fairly monetise free Flash games.

But fast forward a few years, and through apathy (or worse) consumers have come to expect apps and music to be free, while Apple profits.

Eddy Cue:

We hear you @taylorswift13 and indie artists. Love, Apple

#AppleMusic will pay artist for streaming, even during customer’s free trial period

Update (2015-06-22): Kirk McElhearn:

Apple doesn’t pay artists or producers. Ms Swift says nothing about record labels, who, other than for the publishing payment, are the ones who collect the money. This distinction is very important when discussing streaming music. All the streaming services try and claim that they pay “artists,” but they absolutely do not.

When an artist gets paid, it’s by their record label. Standard contracts give a recording artist somewhere around 10% of the record label’s income, after expenses, including a producer’s royalty, for their recordings. Streams are already paid very little, and the artists get a fraction of that.

[…]

Note that Apple won’t be paying the full per-stream rate during the trial period. Peter Kafka of re/code spoke to Eddy Cue[…]

[…]

Second, and this is a much bigger issue, it’s unclear if Apple can actually pay the rights during this trial period and not get targeted by competitors for predatory pricing or anti-competitive behavior.

Charles Perry (tweet):

This debate is important to app developers because, whether we like it or not, digital music has been devalued – just as our digital creations have been. In just a few short years people have gone from paying tens of dollars for an album, to paying 99 cents for a single track, to paying pennies or even nothing to stream an entire library of music. This parallels in a rather frightening way the history of the App Store where, in an even shorter amount of time, mobile software that once sold for tens of dollars now is lucky to sell for 99 cents. Just as the music industry, now including Apple, has moved to an “all-you-can-eat” subscription model to bring down the per title cost of music below that 99 cent threshold, it now doesn’t seem unreasonable that a similar all-you-can-eat subscription model might be used to allow per title pricing of apps to fall below 99 cents as well.

Steve Streza:

Taylor Swift yells about getting paid for trials, and @cue responds in hours. App developers scream about sustainability for years, nada.

Wil Shipley:

I’m not the first to say it but gosh it’d be nice to get some love for indie developers as well as indie artists.

First off, indie developers used to make ~50% of our revenue by giving discounted upgrades to existing customers. Apple blew this away.

Second off, indie developers used to be able to talk to their customers directly. Now customers leave 1-star reviews when they need support.

Third off, indie developers don’t have any real recourse to deal with bad reviews that are actually customers asking for support.

pinaceae:

this was a BRILLIANT pr orchestration.

blogs, articles, etc all over the globe were written about apple music, for free. would have been far more expensive to buy all that airtime than this little scandal.

so taylor swift gets more publicity, apple music is now an established brand name, everyone and their dog knows about their pricing model - holy shit. hats off to the apple team, playing the outrage-piano like no other.

I doubt it was planned, but it does seem to have worked out well for both Apple and Swift.

eco:

I’m reminded of the huge success Coke experienced after reintroducing Coca Cola Classic after the disastrous new Coke. When questioned about the whole thing Coke’s president Donald Keough said, “Some critics will say Coca-Cola made a marketing mistake. Some cynics will say that we planned the whole thing. The truth is we are not that dumb, and we are not that smart.”

Update (2015-06-23): Eli Schiff (comments):

Apple’s impulsive response to Swift stands in stark contrast to their treatment of indie app developers, who have been lobbying Apple for almost seven years, requesting Apple reform policies in the App Store to no effect. In particular, Cue’s use of the word “indie” can only be described as a callous slap in the face given the circumstances that indie developers have been facing.

Developer reactions have been mixed: Daniel Jalkut of MarsEdit exclaimed, “Damn, I wish Taylor Swift were also a Mac App Store developer.” Cabel Sasser rightly pointed out that complaints by developers have and will likely continue to be ignored: “As if ANY of us nerds have 1/100000th the public perception pull of a Taylor Swift.”

Developer David Barnard pointed out the utter inconsistency here between music and app development: “Apple is subsidizing a 90 day free trial for Music, but there’s still a rule in the App Review Guidelines prohibiting timed trials for apps.” In other words, musicians complain that they will not get paid—Apple immediately subsidizes them. Developers on the other hand do not even have the option of using that marketing strategy.

Update (2015-07-12): Ben Sisario (via John Gruber):

For each song that is streamed free, Apple will pay 0.2 cent for the use of recordings, a rate that music executives said was roughly comparable to the free tiers from services like Spotify. This rate does not include a smaller payment for songwriting rights that goes to music publishers; Apple is still negotiating with many publishers over those terms, several publishing companies confirmed on Wednesday.

Update (2015-07-14): Michal Lev-Ram (via Konra):

Scott Borchetta—who discovered and signed Swift when she was only 14 years old—told the audience that the conversation actually started between him and Apple in the days preceding Swift’s letter.

[…]

“She literally texted me and said, ‘Don’t be mad,’ with the link,” Borchetta said. “She was in Europe. I responded and said, ‘You don’t have any idea how good your timing is right now.'”

After Swift’s letter made huge waves, Borchetta’s conversations with Apple quickly turned to his (and, presumably, artists’) favor.

Update (2015-08-21): Mitchel Broussard:

In a new interview with Evening Standard, Apple Music executive and Beats co-founder Jimmy Iovine sat down to talk about everything from the launch of Apple Music to the company’s dramatic reversal of its free trial royalties policy following Taylor Swift’s public dismissal of the service in an open letter.

Mitchel Broussard:

In an interview for the September cover story of Vanity Fair, Taylor Swift reveals her thoughts and reasoning behind the letter she wrote to Apple concerning the lack of monetary support for artists during Apple Music's three-month free trial period. The singer notes that she wrote the letter in the early morning hours after a few of her fellow artists sent pictures of their Apple Music contracts.

Oscar Raymundo:

“Apple treated me like I was a voice of a creative community that they actually cared about,” Swift told Vanity Fair. The magazine calls Swift an “Apple Music crusader” with the “willingness to take on tech giants.”