Archive for October 31, 2017

Tuesday, October 31, 2017

HomePod to Run Apps Through iPhone/iPad

Apple:

iOS 11.2 introduces SiriKit for HomePod, the powerful speaker that sounds amazing, adapts to wherever it’s playing, and provides instant access to Apple Music. HomePod is also a helpful home assistant for everyday questions and tasks. With the intelligence of Siri, users control HomePod through natural voice interaction. And with SiriKit, users can access iOS apps for Messaging, Lists, and Notes.

Mark Gurman:

Voice apps don’t run on the HomePod, HomePod serves as a speaker to the iPhone. Only works with SiriKit for messaging, notes, and list apps.

So, no apps like Uber/Lyft (would have been perfect for the HomePod), no new Siri functionality for apps like Spotify (obvious-ish).

Benjamin Mayo:

The HomePod listens for a request from a user. If it recognises it as a request meant for a third party app, it sends the necessary data to a nearby iPhone/iPad with the app installed. The iOS device sends the response back to the HomePod, which speaks the reply. It’s similar to how WatchKit 1.0 worked where the connected phone did all of the heavy-lifting for third-party Watch apps.

[…]

Most significantly for HomePod is how it behaves as a device shared by multiple people. Or more accurately, how it seemingly ignores any such attempt to be a shared home product at the software level. It seems like one user will sign into the HomePod with Apple ID and iCloud, and all Siri features will be funnelled through that one account. This applies to first-party and third party services.

Update (2017-11-01): Manton Reece:

The problem for Siri is that Apple’s competition with Amazon and Google isn’t on a level playing field. Siri won’t “catch up” to Alexa because the architectures are fundamentally different, with SiriKit locked to the device while Alexa expands quickly to new products and thousands of extensible skills in the cloud.

Selective Selector Mapping

Daniel Jalkut:

It turns that adding that protocol conformance onto my class declaration not only gains me Swift’s protocol type checking, but changes the way key functions are mapped from Swift to Objective-C:

class MyDataSource: NSObject, NSTableViewDataSource {
    func numberOfRows(in tableView: NSTableView) -> Int {
        return 0
    }
}

let thisSource = MyDataSource()
thisSource.responds(to: Selector("numberOfRowsInTableView:")) // true

Armed with the knowledge that my class intends to comply with NSTableViewDataSource, Swift generates the expected mapping to Objective-C.

Super Mario Run’s Disappointing Profit

Andrew Webster (via John Gruber):

Nintendo’s first mobile game, Super Mario Run, was enormously popular — but that doesn’t mean it was a success for the company. During its most recent earnings report, Nintendo revealed that Mario Run has been downloaded 200 million times, 90 percent of which came from outside of Japan. However, Nintendo says that despite these big numbers, the game has “not yet reached an acceptable profit point.” While Nintendo didn’t reveal any specifics with regards to conversion rates, a big sticking point for many with Super Mario Run was its comparatively large price point; it’s free to download, but requires a one-time fee of $9.99 to unlock the whole game.

Previously: Super Mario Run.

Update (2017-11-01): See also: John Voorhees.

Update (2017-11-07): Adam Blacker:

While Mario definitely benefitted from the price drop, the game would have seen more conversions at the price point of $1.99. Apptopia firmly believes this to be the optimal price point for a paid app. While Super Mario Run is free to download, the in-app purchase to unlock all of the levels essentially acts in the same way. We estimate that Nintendo lost out on $8M by not pricing Super Mario Run at $1.99. We’re saying they could have increased their revenue by over 1,800% during the promo period.