David Barnard and Paul Haddad are finding that when someone searches for their apps—by exact name—the App Store shows a search ad for a competing app at the top of the search results. This is exactly the sort of thing developers feared when search ads were announced.
DivyB:
Not good - this is exactly what I thought Schiller said wouldn’t happen :(
Update (2016-06-16): @manolosavi is getting both an ad and an organic search result for the same app (via Preshit Deorukhkar). This is also bad because developers shouldn’t have to pay when they are already the top result.
John Siracusa:
Schiller talked about this in The Talk Show live. Short version from memory: this is allowed and benefits small devs more than big.
I’m very skeptical that this is a benefit for developers (who would have to outbid others just to protect their own app’s name as a search term) or for users (who expect what they search for to be at the top). Note, also, how the ad takes up more of the screen than the actual matching search result.
Nick Heer:
A very large company like Facebook could conceivably bid on all major social networking keywords, for example, and push down any competitors on the search results page. Or, in a more nefarious scenario, a well-funded low-quality or knockoff app could bid its way to the top of search. I’d hope Apple puts a stop to this; it would be inadequate to simply add “Report” buttons for ads that engage in this sort of behaviour.
Update (2016-06-17): Searching for PCalc shows an ad for PCalc Lite above the actual Calc.
Update (2016-06-20): Phil Schiller talked more search ads at The Talk Show Live.
Update (2016-06-21): Another example from Paul Haddad.
Update (2016-06-27): Rebecca Slatkin:
Watching ‘Introducing Search Ads’ so in a few years when all my indie developer friends go back to consulting I’ll know why.
“Because user experience is so important to us..”
I never thought Apple would ever give into making $ this way
Apple claims to possess a unique set of values and beliefs including raising the bar. Pretty sure this does the opposite.
Gus Mueller:
It’s like modern Apple though. Ask yourself, who does this help?
Daniel Jalkut:
I have asked, and can’t think of anybody but deep-pocketed developers with non-definitive search results.
Update (2016-07-02): Asher Vollmer (via Cabel Sasser):
An ad for 2048 shows up at the top of the @AppStore when you search for “Threes” in iOS 10.
This is exhausting.
Update (2016-07-10): Daniel Jalkut:
I am rarely as convinced that an Apple move is bad as I am with paid App Store placement. It defies my understanding of Apple’s values.
Update (2016-07-15): SplitMetrics:
The fact that the app in the first place got more clicks than the one on the 4th place was rather predictable. But the difference in those clicks is surprising: moving from the 4th place to the 1st increased the traffic share from 1% to 57%.
[…]
In both alternatives, the top app whether it was an ad or not achieved by far the most clicks on the ‘Get’ button. A ‘search ad’ app received 57% of clicks and the top app in a regular search result – 71%. The relatively small gap in CTR means that users don’t see the difference between sponsored and organic listings.
Update (2016-07-28): See also: David Chartier.
Update (2016-08-25): See also: Oisín Prendiville.
Update (2017-01-21): Dan Luu:
Google outbids Mozilla in the AppStore and shows up first for searches on “Firefox”.
Advertising App Store App Store Search Ads Calcbot iOS iOS App Launch Center Pro Phil Schiller Search Threes
In 2011, I wrote:
Would anyone be surprised if future versions of Mac OS X made additional features and APIs available only to App Store apps?
In 2012, this came to pass:
It’s no longer possible to write a single app that takes advantage of the full range of Mac OS X features. Some APIs only work inside the Mac App Store. Others only work outside it. Presumably, this gap will widen as more new features are App Store–exclusive, while sandboxing places greater restrictions on what App Store apps are allowed to do.
In macOS 10.12, this will be less true. Developer ID apps outside the Mac App Store will be able to do almost everything:
Developer ID-signed apps can now take advantage of CloudKit, iCloud Keychain, iCloud Drive, remote (push) notifications, MapKit, and VPN entitlements.
I say “almost” because iCloud key-value storage and Core Data are not mentioned in the document, although my impression from the WWDC session is that they will be included. Of course, this assumes that Apple does not renege on this, as it did with Map Kit and El Capitan.
At WWDC, Apple is presenting the Mac App Store as the preferred way to distribute software. However, it still lags behind the iOS App Store in features. Developer ID apps have access to more APIs and more business models.
Andrew Pouliot:
Feels good to decouple the two, let MAS have its own value proposition apart from CloudKit, vice-versa.
Milen Dzhumerov:
Basically, they remove all the reasons for MAS (together with paying for direct Mac apps using Apple Pay).
Drew McCormack:
Question is whether they have just given up on it. Wouldn’t be the first time Apple just leaves something for dead.
The situation continues to get worse for unsigned apps. In macOS 10.12, the (graphical) preference to enable them has been removed, although there are still ways around that.
Business CloudKit Code Signing Core Data Gatekeeper iCloud Mac Mac App Store macOS 10.12 Sierra Map Kit Push Notifications Sandboxing
Jeff Johnson:
Under what circumstances does App Translocation occur? First, the app must have a com.apple.quarantine extended attribute. If you delete the quarantine xattr, then App Translocation does not occur, and the app will launch from where it was unarchived, like normal. Second, the app must be opened by Launch Services. This usually means Finder, but it can also mean open from Terminal, for example. If you launch the app executable directly from bash, on the other hand, App Translocation does not occur. Third, the app must not have been moved — by Finder. If you move the app, using Finder, from the app’s original unarchived location to another folder, even a subfolder, e.g., ~/Downloads/Test/, then App Translocation does not occur. However, if you move the app using mv from Terminal, then App Translocation will still occur. Normally you would move the app from ~/Downloads to /Applications, and that would cause the app to be launched from /Applications like normal, but the locations of the particular folders don’t seem to matter. The mere act of moving the app using Finder stops App Translocation from happening. Indeed, once you’ve moved the app once, it will no longer experience App Translocation again, even if you then move it back to ~/Downloads.
[…]
How does App Translocation affect us, as app developers? For the most part, the apps seem to work as before. After all, it shouldn’t matter whether your app is launched from /Applications, from ~/Downloads, or from the Xcode build folder. However, when the app runs from a read-only volume, it cannot update itself to a newer version. App Translocation prevents software update mechanisms such as Sparkle from working.
Jeff Johnson:
This is because the vulnerability that Apple is attempting to fix is what the presenter called a “repackaging” problem. The repackaging problem was illustrated at the end of Patrick Wardle’s paper, where he gives an example of a maliciously crafted disk image. It was clear from the session that Apple is concerned not just with Wardle’s dylib hijacking but also with any resources loaded external to the app bundle. Some apps will load external scripts or html, either of which could be employed in an attack. A locally loaded html page has access to the user’s file system, so it could wreak havoc if the page contains maliciously crafted JavaScript. App Translocation was designed to prevent malicious external resources from being loaded by changing the relative paths from the app bundle.
See also: WWDC Session 706: What’s New in Security.
Update (2016-06-17): Jeff Johnson:
The fundamental problem, the primary cause of both of the flaws I discovered, is that App Translocation happens automatically, without any awareness by or notification to the user, but App Translocation is turned off by a manual action by the user — moving the app bundle in Finder — again without any awareness or notification.
[…]
The more I learn about App Translocation, the more I feel that it is a bad idea with a botched implementation.
Update (2016-06-29): Jeff Johnson (tweet, Hacker News):
The problem with Gatekeeper Path Randomization is that copying applications to a read-only disk image will break functionality in many, if not most, existing applications. Perhaps most notable, features like automatic software updates (via Sparkle or similar mechanisms) will no longer work. Apple may not view this as an issue, given that GPR will be disabled once the user moves the application out of the Downloads folder. However, many users run applications from the Downloads folder, never moving them. This is especially common when a user is trying out an application prior to purchasing it, and an app that doesn’t work as expected due to GPR seems certain to lead to lost sales. Worse, even if the customer moves your app to their Applications folder, it may continue to be broken, depending on how your app is packaged.
[…]
Because the vast majority of apps do not load external resources relative to the app bundle path, only a very small percentage of apps are vulnerable to the attack that Gatekeeper Path Randomization is attempting to prevent. Nevertheless, Apple’s current implementation for GPR affects all apps outside the Mac App Store, and the negative impacts will be felt far and wide. While we believe there are several changes Apple can and should make, a simple workaround would be to allow software developers to opt out of Gatekeeper Path Randomization. If an app does not load external app-relative resources, GPR provides no benefit. The app should thus be able to put a key in its Info.plist specifying that GPR should not apply to the app.
Update (2016-06-30): Jeff Johnson:
I respect that Apple had a difficult choice. I’ve been thinking a lot about it, and I’m not sure exactly what mechanism I would use to protect against the repackaging problem. Gatekeeper Path Randomization is flawed, in my opinion, but there is no ideal solution. Any alternative I can think of would also have major downsides. This is why the Info.plist key is so important. The best way to prevent any problems or breakage caused by Gatekeeper Path Randomization is to avoid it completely. And we know it’s not necessary for most apps, because they aren’t vulnerable to repackaging, so there should be an easy way to indicate to Gatekeeper that an app doesn’t need it. It’s not naive to trust developers with an Info.plist key; the whole Gatekeeper and Developer ID system is based on trust. If that trust is violated, then Apple has the ability to revoke a developer’s signing cert, but thankfully the nuclear option has rarely been necessary.
Update (2016-07-11): The public beta version of DropDMG can now create signed disk images to avoid Gatekeeper path randomization.
Update (2016-07-21): DropDMG 3.4 is now available with support for creating signed .dmg disk images and .xip archives.
Update (2016-07-26): Jeff Johnson:
As I mentioned in an earlier blog post, there’s a new API for App Translocation in the 10.12 SDK: <Security/SecTranslocate.h>. However, if you’re sane, you’re not shipping your apps yet with the 10.12 SDK. So how can you detect App Translocation in your shipping apps? The trick is that since you can’t link against the new functions, you have to load them at runtime. I’ve provided sample code below.
Update (2016-08-18): Jeff Johnson:
Therefore, we’re faced with the odd situation where App Translocation affects our apps, but there’s no supported way to detect it, not even with the latest SDK. It’s unclear how this situation can be tenable. As we’ve seen, though, Apple works in mysterious ways. Thankfully, the SecTranslocate symbols still exist in the Security.framework binary, so the technique explained in my last blog post continues to work. The Dude abides.
Update (2016-10-07): Jeff Johnson:
In an earlier post I mentioned that the I stumbled upon a different place where a kind of API for App Translocation still exists in macOS 10.12 Sierra: the security command-line tool. It’s not in the man page, so don’t bother to RTFM, but you will find it at the end of the usage information, when you simply type security into Terminal[…]
Update (2017-02-18): Johannes Tiefenbrunner:
If you put these two things together it becomes impossible to create permanent (“Forever”) rules in Little Snitch for apps that are still in quarantine, because each time they are launched they will be launched from a different path.
Update (2018-06-21): Jeff Johnson:
The kicker is that this App Translocation issue only occurred on Sierra. On High Sierra, the SafariServices API calls work even when the app is running from the Downloads folder and undergoing App Translocation. So it appears that SafariServices on Sierra was failing to account for App Translocation, and that bug was fixed in High Sierra.
Code Signing Disk Image DropDMG Extended Attributes Gatekeeper Mac macOS 10.12 Sierra Malware Security
Andrew Cunningham (Hacker News):
Third parties can use Siri in six different kinds of apps, though those applications encompass a wide range of common and popular App Store offerings: audio and video calling apps; messaging apps; payment apps; apps that allow searching through photo libraries; workout apps; and ride booking apps.
That covers a lot of ground, but there’s a lot that’s missing: music and video apps like Spotify and Netflix, mapping apps like Google Maps, and third-party to-do list apps don’t fall under any of these umbrellas, possibly because they conflict too directly in some cases with Apple apps and services like Apple Maps and Apple Music (Apple Maps in particular is becoming more deeply integrated into the OS with every new update). Hopefully Siri will become more useful to a wider variety of apps later on, but for now the first-party apps are definitely still in a privileged position.
And Apple didn’t draw too much attention to it yesterday, but these Siri capabilities are only available in iOS 10, not in the newly Siri-fied macOS Sierra.
Clark Goble:
This is so inexplicable. Why can’t I pass a search to a weather app to see the weather for a city? Why can’t I start a podcast in a 3rd party podcast app like Downcast. (Honestly, that’s the time I’m using my phone in the car -- much more than sending SMS by voice) Why can’t I ask Daylite to dial a contact? Why can’t I get tomorrow weather for a city I’m traveling to from my weather app of choice?
Honestly the places they open are least useful to me.
Tim Schmitz:
Although I’m happy there’s finally a developer API for Siri, I’m disappointed that it’s limited to a fairly small set of applications for now. As a user, what I want most is for my favorite shopping and to-do list apps to get Siri integration, something that won’t be possible with what Apple announced today.
Husain Sumra:
When asked why Siri’s API is limited to certain kinds of apps, like ride-hailing services like Uber or messaging, Federighi and Schiller once again talked about Apple’s baseline philosophy. Federighi said the decision to go with those apps types was made because Siri largely understands the domains of messaging and requesting purchases, making it easier to give the keys to developers and ensure a great user experience. He also said that Apple is working to expand Siri’s familiarity with certain domains over time.
I think this is fundamentally the wrong approach. Imagine how useful AppleScript would be if you could only use Apple’s standard suites. Adoption and innovation would be greatly slowed, and lots of interesting things would never be possible. Amazon’s approach of letting Alexa Skills add their own terminology makes a lot more sense. I care much more about functionality and reliability than about having lots of variant, more natural syntaxes for the basic queries.
Secondly, I’m disappointed that there is still no easy way to simply save a bunch of dictated text as a reminder (to be imported into OmniFocus). Most of the time, this is all I want to do when hands-free. Instead, if I say “Remember to,” Siri will try to parse the following text and inevitably mess it up.
See also: WWDC Session 217: Introducing SiriKit.
Update (2016-06-16): Joe Rosensteel:
Limitations of SiriKit are baffling when you think about Siri’s universal search for media on the Apple TV.
Update (2016-07-17): Steven McMurray:
In this article we’ll dive deep into how Siri works, the fundamentals of implementing Siri, and how to design a great user experience with Apple’s own personal assistant.
Update (2016-07-18): Ruffin Bailey:
I understand that this allows us to skip translation, but is that really that big a deal? Smart folk are internationalizing (there’s a better word for that; sorry) their apps now, translating labels and other text throughout. I also get that Apple might do a better job with grammar, so that there are lots of ways to get across a command in natural speech rather than forcing a strange, app-specific grammar. I don’t feel that’s a big win.
iOS iOS 9 Mac macOS 10.12 Sierra OmniFocus Reminders Siri
Michael J. de la Merced and Leslie Picker:
How generous is Microsoft’s takeover bid? It puts LinkedIn’s enterprise value at 79 times the social network’s earnings before interest, taxes, depreciation and amortization, or Ebitda, for the 12 months that ended on March 31.
On the basis of that multiple, the transaction is more expensive than any big internet deal paid with cash, according to data compiled by Bloomberg.
Microsoft is paying $220 for each of LinkedIn’s monthly active users. By comparison, when Facebook acquired WhatsApp for $19 billion two years ago, it spent $40 for every user.
Ben Thompson:
LinkedIn builds a bridge for their productivity business to a new world centered around end users, not corporations, and it may even give Microsoft’s inevitable compete products a head start. Imagine this: instead of simply moving Active Directory to the cloud, Microsoft is potentially making LinkedIn the central repository of identity for all business-based interactions: chat, email, and more, and it’s an identity that endures for an end user’s professional life, because it’s managed by the user, not by their transient employer. It’s genuinely exciting, and shocking though it may have been, I think that’s worth $26 billion.
John Gruber:
That’s a lot of money but it seems like an obvious fit. Also, Nadella was probably tired of getting all those LinkedIn emails.
Nick Heer:
Microsoft’s track record with multibillion-dollar acquisitions is, well, terrible. But why would Microsoft want to own the world’s second uncoolest social network — the first, of course, being Google+ — when it’s effectively a glorified and unprofitable résumé hosting service?
Acquisition Business LinkedIn Microsoft
