Wednesday, June 29, 2016 [Tweets]
Daniel Dilger (via Dave Mark):
Like previous App Extensions, the new architecture defines a broad Extension Point for Safari that allows third party developers to add new functionality to Safari, both to read and modify web page content (such as translating text into another language) and to communicate back and forth with a native app to integrate app data into Safari or to get web data into an app.
More importantly, the new App Extensions architecture enables developers to distribute Safari Extensions as part of their app through the App Store.
Safari App Extension Programming Guide:
Safari app extensions are available in OS X 10.12 and later and in OS X 10.11.5 when Safari 10 is installed. Using a Safari app extension, you can add new functionality to Safari, read and modify web page content, and communicate with your native application to integrate its content into Safari or send web data to your app.
Because there are no standardized, widely accepted behaviors for input masks, it’s best to avoid «magical» behaviour (e.g. automatically entering characters that the user did not type), or, if you do need magical behavior, also account for user behavior that does not expect magical behavior.
For example, if the field auto-tabs to the next field, and the user also tabs right after filling in a field, it might be best to ignore the user’s tab.
If you create a new control that kind of looks like an existing control, the new control should not violate people’s expected behavior of the existing control. In other words, text fields with input masks’ behavior should be as close to a normal text field’s behavior as possible.
To most readers of this blog, the fact that fonts are a very significant attack vector does not have to be reiterated. There are a number of different file formats in active use. These formats are extremely complex, both structurally and semantically. As a result, they are correspondingly difficult to implement correctly, which is further amplified by the fact that a majority of currently used font rasterizers date back to (early) 90's, and were written in native languages such as C or C++. Controlled font files are also deliverable through a variety of remote channels – documents, websites, spool files etc. Last but not least, the two powerful virtual machines executing programs describing glyph outlines in the TrueType and OpenType formats have proven vastly useful for creating reliable exploitation chains, thanks to the ability to perform arbitrary arithmetic, bitwise and other operations on data in memory. For all of these reasons, fonts have been an attractive source of memory corruption bugs.
If nothing else, the effort and its results are evidence that fuzzing, if done correctly, is still a very effective approach to vulnerability hunting, even with theoretically “mature” and heavily tested code bases. Furthermore, the two bug collisions prove that Windows kernel font bugs are still alive and kicking, or at least were actively used in the wild in 2015. In the second post of the series, we will discuss the meaty parts of the research: how we prepared the input corpus, mutated and generated interesting font samples, fuzzed the Windows kernel at scale, reproduced the crashes and minimized them.
VintageApple (via Clark Goble):
There is no better depiction of the history of the Macintosh than the old issues of MacWorld Magazine.
For your reading pleasure is a complete MacWorld Magazine collection from
1984 through 1994.
Color scans in PDF format. I really enjoyed flipping through some old issues of Macworld (note the capitalization) recently before recycling them. The ads, in particular, are very different from what we’re used to seeing now.
Tuesday, June 28, 2016 [Tweets]
Kay Yin (via Accidental Tech Podcast):
Photos app supports detecting 4,432 different scenes and objects. These scenes or objects can be searched for in all languages.
Additionally, you can search for various landmarks. For example, Photos can respond for search query of “Maho” (beach in Saint Martin), despite Photos is not programmed or trained to understand specific landmarks. Behind the scenes, Photos app first generates a generic categorization for the scene, “beach”, then searches through a built-in dictionary for all landmarks that has the name “beach” in its definition. Therefore, cleverly, despite Photos app knows nothing about “Maho” in particular, it is still able to return the right results. The same applies to nature scenes, water scenes and urban scenes.
For your pleasure, here’s a comprehensive list of scenes you can search for.
I would love to see this kind of thing in Lightroom.
It’s not just the format itself, but how it is used. Because Scrivener projects comprise many files, it’s important that any given project is synced in its entirety and not piecemeal. If an updated binder structure is downloaded, it’s not much use if none of the new files it references are yet available, for instance. Dropbox gives us the control we need in this regard.
This is also the reason that the sync needs to be invoked manually rather than continually happening in the background. With background sync (which iCloud always uses), there is no control over which files appear when, meaning that important structural files could download without the files they refer to or vice versa. This is an even more serious problem when the connection is lost part-way through a sync. All too easily this could put a project into an inconsistent state that could wreak havoc, and we’d rather have users complaining that they don’t like manual sync than that they have just lost four hours of writing or structural changes!
Birch Outline (via Jesse Grosjean):
Cross-platform scripting for TaskPaper.
Items each of which has attributes and an
- Runtime: Change events, undo support, query evaluator, and relative date/time parsing.
- Serialization: Read/Write .taskpaper, .opml, and .bml
There’s also a Swift wrapper.
Another day, another rumor that Apple is going to ditch the headphone jack on the next iPhone in favor of sending out audio over Lightning. Or another phone beats Apple to the punch by ditching the headphone jack in favor of passing out audio over USB-C. What exciting times for phones! We’re so out of ideas that actively making them shittier and more user-hostile is the only innovation left.
Look, I know you’re going to tell me that the traditional TRS headphone jack is a billion years old and prone to failure and that life is about progress and whatever else you need to repeat deliriously into your bed of old HTC extUSB dongles and insane magnetic Palm adapters to sleep at night. But just face facts: ditching the headphone jack on phones makes them worse, in extremely obvious ways. Let’s count them!
Should the analog headphone jack remain on our devices forever? If you think so, you can stop reading. If not, when? Maybe now is the wrong time, and Apple is making a mistake. I don’t know. None of us outside the company seem to know, because all that has leaked is that the new iPhone won’t have the port, with no explanation why. But I say at some point it will go away, and now seems like it might be the right time. Also, historically, Apple has proven to be very good at timing the removal of established legacy ports.
If it weren’t for Apple we’d probably still be using computers with VGA and serial ports. The essence of Apple is that they make design decisions “no one asked for”.
And in five years we’ll look at analog headphone jacks the way we look at all the other legacy ports we’ve abandoned.
As if Apple should make a change just because this port is old. No, the right question is not “when”, it’s this: Is the proposed solution better enough than the status quo to justify a disruptive transition?
We don’t know how Apple will position it as superior, as John acknowledges right here. We’re just supposed to assume that this is a better solution, and that it “seems like it might be the right time”, based on… who knows. Until Apple answers that question, which they yet haven’t done publicly or through controlled media leaks, we can only speculate.
So barring some bombshell announcement that changes how we think about digital headphones, this is a step forward and 7 steps back.
It is nigh impossible in mobile for existing customers to “just vote with your wallet” any more without significant time and cost.
What is good for Apple is not inherently good for you. There are times when what Apple does is in sync with what benefits their customers, such as in areas of privacy and security. But that same company released Apple Maps when it was literally years away from being ready for the real world, because it benefitted them to not deal with Google. The same company that forced U2 into everyone’s iTunes libraries without consent as a marketing ploy. The same company that made their music app frustratingly difficult to use so they could shove their subscription service into every nook and cranny of the user interface. Apple is not on your side by default.
I didn’t argue that this change will be good for users. I argued that it could be. We don’t know yet!
One of the ideas I’ve seen bandied about regarding the purported removal of the standard headphone jack on this year’s new iPhones is that maybe it’s because the iPhone is switching from Lightning to USB-C. […] I say no way.
What if Apple is planning on Bluetooth earbuds that include a Lightning jack, like the Pencil? Plug them in to the device you want to pair them with, tap “Pair”, and you’re done. Easy to charge, too. (But again, this only works across iOS and Mac if Macs gain Lightning ports.)
See also: Marco Arment on The Talk Show.
The bottom line for me is that no one seems to have any idea what the benefits would be to justify the hassle. The TRS connector is not as obviously antiquated as the floppy drive was. And Lightning and Bluetooth headphones are possible without removing it. I most often use the headphone jack in the car or on a plane when I’m simultaneously charging the phone via the Lightning port. It sounds like doing this with the iPhone 7 would require dongles, if it’s possible at all.
Sidenote: I think the real problem with the original iMac was not the lack of a floppy drive—you could easily add an external one if needed—but the removal of high-speed I/O. The CD drive was not writable, and flash drives were not yet plentiful. USB 1.1 was an improvement over serial ports, but it was terrible for connecting external storage. SCSI was removed and replaced with nothing until the iMac DV added FireWire.
Monday, June 27, 2016 [Tweets]
Michael Flarup (via Nick Heer):
I think it’s great that Apple wants to provide templates for the design resources they’re asking developers to deliver, but the ones they’ve put out is not only a lot less practical than the 3rd party resources available, they’re also factually wrong — using bitmap roundrects instead of the platform standard squircle. Until Apple feels like dedicating more time to helping developers deliver better assets, it looks like there’ll be plenty of reasons why we still have 3rd party resources around.
As you may recall, back at the start of this year I was bitching about the [AppleScript] team adding a native library loader to AppleScript in 10.9 yet bizarrely forgetting to provide any general-purpose libraries along with it, after which I decided to go write the damn things myself just so AS users would at least have something decent to use. The result was a set of seven ‘standard libraries’ (plus one support and one code testing library) providing commands for a wide range of everyday tasks[…]
Anyway, long story short, I got it about 98% done before running out of both time and motivation - the implementation is feature-complete and generally pretty polished and bombproof, but there’s still some holes to fill in test coverage and user documentation.
So, if the AppleScript community would like a chance to help itself then here it is: I want someone experienced in AppleScript and [AppleScriptObjC], and preferably with some actual programming skills as well (cos this is not just toy code), to step up and officially take the whole project over from me over the next couple of weeks. That’s full ownership, BTW: all copyright, choice of license, project management, etc.
Here’s the GitHub project.
Apple executives explained to us that we cannot showcase a homescreen springboard image within the app — stating that the springboard was Apple’s IP and it was against Apple’s Brand guidelines.
The rejection was not only disappointing and heart-breaking for us, as we had put several months of hard work into the app, but we also found the reason very hard to believe.
Homescreen.me is merely a platform that showcases user submitted content, something that other apps like Twitter, Facebook, Reddit etc. already do. Example — what if someone shares a homescreen image on Twitter? Is that a violation too?
Unfortunately, Apple just wouldn’t budge. A work-around, we were told, was to offer users a simple text area where they can type which apps they use on their Homescreens.
Update (2016-06-27): Nick Heer:
Betaworks launched a similar app called “#Homescreen” which, though it had app review issues of its own, was never sanctioned for intellectual property issues.
Update (2016-06-29): Hwee-Boon Yar:
I built an app that simulates homescreen for testing icons. Similar problem.
Some iOS and Mac users are currently unable to access the App Store, Mac App Store, and iTunes Store, according to reports from MacRumors readers and Twitter users.
Apple’s system status page has not yet been updated to reflect any kind of outage and it is not clear how many users are affected.
Today’s outage comes a few weeks after a previous widespread outage took out Apple Music, iCloud Music Library, and iCloud. Apple has previously remained quiet when these outages occur, relying on using the System Status page to communicate to customers of any issues. Zac Hall had previously delved into how Apple should better handle these situations, especially when they expect customers to put more faith in them for future cloud-based services.
Yesterday’s App Store sale numbers. Ouch! #outage
Previously: App Store Search Is Currently Broken.
Friday, June 24, 2016 [Tweets]
Obviously, Apple didn’t go to all that trouble only because they wanted us to use a different (and obviously better) API. The UserNotifications framework actually gives us access to many new, long-awaited features.
Update (2016-06-27): Nick Heer:
Unfortunately, these enhancements haven’t made their way into MacOS.
This morning we’re gonna talk about Objective-C and Swift interop. We’re gonna talk about it really from two perspectives. We’re gonna talk about it from a theoretical perspective, that of language design. […] And then we’re gonna talk about what it was like for us to take a […] 20,000 to 30,000 line Objective-C app, and start adding 20,000 to 30,000 lines of Swift to it, and to add those lines in a very Swifty style.
Interoperability makes it possible to integrate [Swift] features back into Objective-C code with no hassle […] without having to rewrite the entire app in Swift at once.
This is a quote from the Swift book, this is a lie from the Swift book. It’s a nice lie. I mean, it’s kind of true. It’s kind of true if you write bad Swift. But then, it’s basically just syntax sugar versus Objective-C, which is nice, but which is maybe not worth the complexity. […] Okay, so we had this plan, because the Swift book told us this thing, and we believed it. And we embarked about 13 months ago on a large project, we being Khan Academy, to write a large product in Swift, large existing code based, running a large new product.
It was not great, it was emphatically not great. So along the way, we were constantly forced to rewrite large swathes of our app in Swift as we went, or we were forced to decide not to use Swifty idioms and semantics, which is not a decision that we really enjoyed having to make. I think it’s fine. I’m not saying, “Oh, you shouldn’t use Swift in existing apps.” But what I am saying is, “You should add a lot of padding to your estimates.” ‘Cause it slowed everything down a lot, for months. Many, many, many months. And so there’s people out there who are just saying “Well, screw it. I’m just gonna rewrite the whole thing in Swift.” I don’t know, that might have been a better strategy. Transliterating Objective-C to Swift is pretty easy.
This is a conference talk from November 2015, before Swift 2.2 and Swift 3, but a lot of the issues still apply.
Andrew Tridgell (PDF, via @CompSciFact):
This thesis presents efficient algorithms for internal and external parallel sorting and remote data update. The sorting algorithms approach the problem by concentrating first on highly efficient but incorrect algorithms followed by a cleanup phase that completes the sort. The remote data update algorithm, rsync, operates by exchanging block signature information followed by a simple hash search algorithm for block matching at arbitrary byte boundaries. The last chapter of the thesis examines a number of related algorithms for text compression, differencing and incremental backup.
We have used protocol and protocol extensions to make our code more readable.
We have also used a few other tricks, but the main gist is that you can create small helpers in your code to make your life easier, and make life easier for other people that have to read your code. Using old APIs is great because they have been battle-tested; it is code that has been around for many years… and, for many years, bugs have been fixed. But we can make these APIs even better (and make our lives easier).
When we create these helpers, it is important to keep the spirit of the original implementation. We want to make it easy for other people who read the code, and that who may not know about these wrappers.
Thursday, June 23, 2016 [Tweets]
SE-0099 (via Erica Sadun):
Swift condition clauses appear in
while statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions,
let conditions (which test and unwrap optionals), general
case clauses for arbitrary pattern matching, and availability tests. It removes
where clauses from optional binding conditions and case conditions, and eliminates gramatical ambiguity by using commas for separation between clauses instead of using them both to separate clauses and terms within each clause. These modifications streamline Swift's syntax and alleviate the situation where many Swift developers don't know they can use arbitrary Boolean conditions after a value binding.
Objective-C developers learning Swift often wonder how to represent something like
UIViewController<MyProtocol>. The simple answer is that there's currently no way to directly represent that construct in Swift as of Swift 2.2. However, it's possible to work around it fairly easily with just a tiny bit of extra code.
Andy Greenberg (Hacker News, MacRumors):
“We believe you should have great features and great privacy,” Federighi told the developer crowd. “Differential privacy is a research topic in the areas of statistics and data analytics that uses hashing, subsampling and noise injection to enable…crowdsourced learning while keeping the data of individual users completely private. Apple has been doing some super-important work in this area to enable differential privacy to be deployed at scale.”
Differential privacy, translated from Apple-speak, is the statistical science of trying to learn as much as possible about a group while learning as little as possible about any individual in it. With differential privacy, Apple can collect and store its users’ data in a format that lets it glean useful notions about what people do, say, like and want. But it can’t extract anything about a single, specific one of those people that might represent a privacy violation. And neither, in theory, could hackers or intelligence agencies.
Matthew Green (Hacker News):
To make a long story short, it sounds like Apple is going to be collecting a lot more data from your phone. They’re mainly doing this to make their services better, not to collect individual users’ usage habits. To guarantee this, Apple intends to apply sophisticated statistical techniques to ensure that this aggregate data -- the statistical functions it computes over all your information -- don’t leak your individual contributions. In principle this sounds pretty good. But of course, the devil is always in the details.
The total allowed leakage is often referred to as a “privacy budget”, and it determines how many queries will be allowed (and how accurate the results will be). The basic lesson of DP is that the devil is in the budget. Set it too high, and you leak your sensitive data. Set it too low, and the answers you get might not be particularly useful.
A much more promising approach is not to collect the raw data at all. This approach was recently pioneered by Google to collect usage statistics in their Chrome browser. The system, called RAPPOR, is based on an implementation of the 50-year oldrandomized response technique.
The main challenge with randomized response systems is that they can leak data if a user answers the same question multiple times.
What we know about anonymization is that it’s much harder than people think, and it’s likely that this technique will be full of privacy vulnerabilities. (See, for example, the excellent work of Latanya Sweeney.) As expected, security experts are skeptical.
Microsoft Research the birth place of Differential Privacy has abandoned it.
In order to asses accuracy/utility/privacy trade-off correctly one must posses enough information about queries expected, and how much privacy budget should be allocated towards them. Keeping track of queries and budget consumed is even more difficult. Certain tasks require answers to be computed as exactly as possible. The impact from answering such queries and resulting depletion of privacy budget has never been examined in literature.
There have been few attempts at rigorously evaluating privacy budgets and parameters such as epsilon. However they have only shown Differential Privacy to be impractical.
You will encounter strong resistance and in some cases outright bullying from vocal supporters of Differential Privacy. These people will likely be completely unfamiliar with your area of application and existing practices. They will barge in into public meetings proclaiming that Differential Privacy is the only real solution. And that researchers who have spent years working with data in that field should be ignored. Even when several papers have called for further study of Differential Privacy before adoption in practice.
Moritz Hardt presents a “Tutorial on Differential Privacy in the Theory Community” at the DIMACS Workshop on Recent Work on Differential Privacy Across Computer Science, held Wednesday, October 24th 2012 at the Computing Research & Education Building on Busch Campus of Rutgers University. This event was presented under the auspices on the DIMACS Special Focus on Information Sharing and Dynamic Analysis and the DIMACS Special Focus on Cybersecurity.
Update (2016-06-27): Juli Clover:
There’s been a lot of confusion about differential privacy and what it means for end users, leading Recode to write a piece that clarifies many of the details of differential privacy.
First and foremost, as with all of Apple’s data collection, there is an option to opt out of sharing data with the company. Differential data collection is entirely opt in and users can decide whether or not to send data to Apple.
Wednesday, June 22, 2016 [Tweets]
Amazing tip from Xcode labs: add a
EXCLUDED_SOURCE_FILE_NAMES build setting to conditionally exclude sources for different configuration.
There’s also an
INCLUDED_SOURCE_FILE_NAMES, and they can be used together (exclude that, but include this).
A major change from Xcode 7 is that Xcode now requires that every target in your project specify a development team, even when the manual code signing option is selected.
PROVISIONING_PROFILE_SPECIFIER build setting will impart the desired team information to Xcode, even if provisioning profiles are not used.
This doesn’t exactly solve the challenge for open source projects, because organizations using an open source project will still have to override the configuration file or build settings for the projects they check out.
So, the fix in Xcode 8, with the 10.12 SDK, is to delete those parentheses so Swift appreciates that it’s accessing a property. But doing so will break the build back on the 10.11 SDK. What’s a forward-looking, backward-looking developer to do?
Unfortunately, I think the only way to convince Swift to absolutely ignore the problematic line is to use a Swift compiler check, instead. Note that this is a bad solution because we are fundamentally not concerned about the version of Swift being used.
In my opinion, we need a compile time, conditional code exclusion that operates on the SDK, similarly to #available. Something like “#if sdk(OSX 10.12)”. As far as I know, nothing like this exists.
Source Extensions have several capabilities and are organized around commands. Each extension can provide a list of commands in its plist file or via an override of
XCSourceEditorExtension. Each command specifies what
XCSourceEditorCommand subclass implements the command, the name on the menu, and a unique identifier. The same class can implement several commands by switching on the identifier.
The first parameter is an
XCSourceEditorCommandInvocation. That invocation has the contents of the editor’s text buffer (either as a single string or as an array of lines). It also has the selections, and each selection has a
end that tell you the line and column (which can be used to index into the text buffer’s
lines array). If nothing is selected, the single
XCSourceTextRange in the array will have the same
end point representing the insertion point.
See also: WWDC Session 414: Using and Extending the Xcode Source Editor.
Update (2016-06-23): Jay Graves:
Xcode 8 brings the dark art of customized code signing and provisioning profiles into the light for all to see. Instead of being buried in the Build Settings, Code Signing is now displayed front and center in the General tab. When “Automatically manage signing” is unchecked we can specifically select the provisioning profile we wish to use for each Configuration. Now this in itself is nothing new, we have always been able to do this in the Build Settings tab. The awesome sauce comes in with the smarts that Xcode 8 displays here. The drop down list of profiles now groups the Eligible profiles above the Ineligible profiles. Meaning that profiles that match the bundle identifier absolutely or with a wild card will be displayed above any profiles that don’t match at all.
The Xcode team has included a new report in the Report Navigator that outlines everything Xcode does on your behalf related to code signing.
Update (2016-06-29): James Thomson:
Xcode 8 no longer supports iOS 7 as a deployment target, so if you add support for iOS 10, you’ll lose iOS 7 support.
I took a break from converting projects to Swift 3 this weekend and instead played around with writing a new “Source Editor Command” extension for Xcode 8. The result is an extension that detects and corrects whitespace issues. It’s a topic I’ve touched on before because I’m frustrated by the continuous burden of correcting whitespace in my projects. I wanted to see if an Xcode source extension could reduce my annoyance with this issue.
The fun part of this exercise for me was writing a pushdown automaton parser where all of the parser logic was expressed through the
case patterns of a single Swift
switch statement. Accordingly, most of this article is not really about Xcode Source Editor Command extensions or whitespace issues but is actually about design choices related to large, complex
switch statements in Swift: choosing data types to
switch upon, designing
case patterns to handle a deep decision tree in a single
switch statement, when to use custom pattern matching and when to use
I’m pleased to announce the release of Script Debugger 6. This release introduces over 25 new features and embraces modern AppleScript, including AppleScriptObjC. To sweeten the deal, Script Debugger’s price has been reduced by 50%!
Late Night Software:
If you distribute scripts, chances are you want them to pass muster with Mac OS X’s Gatekeeper, and that means code signing them. Script Debugger 6 makes this task almost invisible with its always-on code signing. Turn it on, and your script is code signed every time it is saved. No more exporting, no more forgetting.
AppleScript’s progress properties are a great way of displaying a script’s progress in an applet, and now you can display them as you run your scripts in Script Debugger 6.
Before Script Debugger 6, working with AppleScriptObjC required specialist software. This powerful technology often requires you to type verbose code, and is unforgiving about case — something foreign to typical scripters. Script Debugger 6’s code completion tools do much of the typing for you and address common problems. Debugging AppleScriptObjC is a bear because AppleScript cannot display values you are working with. Script Debugger 6 fixes this by displaying AppleScriptObjC values as you step through your code — there is no more guessing.
Script Debugger 6 Release Notes:
Script Debugger 6 at long last provides code folding where you can collapse block structures and comments within your code to reduce clutter when editing.
Script Debugger 6 performs each script compilation in a new AppleScript compiler instance. This avoids a long standing problem where it was impossible to change the case of a variable, property, handler or script object once the script had been compiled.
Update (2016-06-29): See also: Howard Oakley.
I’m not a big Unix fan -- it was too late on the scene for the level of ideas that it had -- but if you take the cultural history it came from, there were several things they tried to do that were admirable -- including really having a tiny kernel and using Unix processes for all systems building (this was a very useful version of “OOP” -- you just couldn’t have small objects because of the way processes were implemented). It was quite sad to see how this pretty nice mix and match approach gradually decayed into huge loads and dependencies. Part of this was that the rather good idea of parsing non-command messages in each process -- we used this in the first Smalltalk at Parc -- became much too ad hoc because there was not a strong attempt to intertwine a real language around the message structures (this very same thing happened with http -- just think of what this could have been if anyone had been noticing …)
It used to be the case that people were admonished to “not re-invent the wheel”. We now live in an age that spends a lot of time “reinventing the flat tire!”
The flat tires come from the reinventors often not being in the same league as the original inventors. This is a symptom of a “pop culture” where identity and participation are much more important than progress…
When the first Turing Award winner -- Al Perlis -- was asked in the 60s “What is Computer Science?”, he said “It is the science of processes!”. He meant all processes including those on computers, but also in Biology, society, etc.
His idea was that computing formed a wonderful facility for making better models of pretty much everything, especially dynamic things (which everything actually is), and that it was also the kind of thing that could really be understood much better by using it to make models of itself.
I’ve been constantly surprised about how what I called “object-oriented” and “system-oriented” got neutered into Abstract Data Types, etc., (I think because people wanted to retain the old ways of programming with procedures, assignment statements, and data structures. These don’t scale well, but enormous amounts of effort have been expended to retain the old paradigms …
Tuesday, June 21, 2016 [Tweets]
Things are different with Swift 3.0. The
init! indicates that the initialization process can fail, and if it doesn’t, that the resulting instance may be forced (i.e., implicitly unwrapped). Unlike in Swift 2.x, instances resulting from
Optionals and not
ImplicitlyUnwrappedOptionals. That means you will have to employ optional binding or chaining to access the underlying value.
We never explicitly declared that
nilPerson should be an
ImplicitlyUnwrappedOptional. And it’s not great that the compiler inferred unsafe type information.
Swift 3.0 solves this problem by treating
Optional unless we explicitly declare that we want an
Gone is the awkward mix of swiping: Instead, the Lock screen as displayed takes advantage of content in each direction; swipe from the top for Notification Center, right for the Widgets screen, left for the Camera app, or bottom for Control Center. Along the bottom of the Lock screen are page indicators like those on the Home screen — another indicator that more content hides out of reach on each side.
With these changes, iOS 10 paints a much clearer visual map for users, built in layers: On the top layer, you have Actions: Notification cards, Widgets, Control Center, and 3D Touch options; on the bottom layer, you have the Home screen; and the middle layer holds your Lock screen (if locked) or other app-related content (if unlocked).
By making each bit of iOS UI its own distinct layer, this also opens up greater horizontal interactions, as with Control Center. As seen in the keynote, Control Center now lives inside a hovering bubble layer, with a Music widget and Home widget just a left swipe away.
As part of iOS 7, Apple bet big on thinner font faces legible at small sizes; with iOS 10, the company is re-embracing font size and weight.
In part, the bigger font faces provide for readable, tappable touch targets: In the future, instead of stabbing furiously at the tiny mini-player on the bottom of the iOS 9 app, I can look forward to tapping an element double in size, with clearly demarcated play/pause buttons and no More (...) button in sight.
I like these buttons that look like buttons in iOS 10.
By default, Safari  no longer tells websites that common plug-ins are installed. It does this by not including information about Flash, Java, Silverlight, and QuickTime in
navigator.mimeTypes. This convinces websites with both plug-in and HTML5-based media implementations to use their HTML5 implementation.
When a website directly embeds a visible plug-in object, Safari instead presents a placeholder element with a “Click to use” button. When that’s clicked, Safari offers the user the options of activating the plug-in just one time or every time the user visits that website. Here too, the default option is to activate the plug-in only once.
Monday, June 20, 2016 [Tweets]
It’s kind of amazing we made it this far - only TidBITs and MacWorld are older and still around - but we’ve been told we’re packing it in. We’ve joked before that Apple becoming a huge mainstream company is the worst thing that ever happened to us, but it’s true: there’s less need for an Apple-specific news site when news about Apple is plastered everywhere, on every site, all the time. This is not the sole reason why we’re having to give up our comfy home (and just after repainting it, too!), but it’s part of the reality we’ve been working in.
I’ve been reading MacNN since the beginning. It was one of the essential “blogs” from the early Mac Web, along with sites like MacInTouch, MacFixIt, MacCentral, and The Mac Resource Page.
Since Mac OS X 10.9, Xcode hasn’t followed the normal system preferences for controlling font smoothing. Lately, I’ve been using a plug-in to work around this. Xcode 8 has a new editor extensions feature but won’t load old-style plug-ins. Fortunately, Xcode 8 has changed so that it now respects the standard screen fonts preference, without having to use a plug-in:
defaults write com.apple.dt.Xcode NSFontDefaultScreenFontSubstitutionEnabled -bool YES
Note that whereas before, the preferences window would obey the setting but the text editor wouldn’t, now it’s the reverse. You can’t see the actual fonts as you’re choosing them, but they do work when you’re editing code. Unlike in other apps, the font smoothing in the editor seems to be either completely off or completely on. It does not respect the
AppleSmoothFixedFontsSizeThreshold setting to only disable smoothing for smaller sizes.
Friday, June 17, 2016 [Tweets]
In March 2013, I chronicled the problems developers were having with Core Data iCloud syncing. Many concluded that the basic
NSPersistentStoreUbiquitousContent design was flawed. Bugs could be fixed, but it would never be able to do what people wanted. Apple didn’t give the impression that it thought there were major problems. It kept reporting minor improvements and bug fixes. When CloudKit was announced in 2014, it had no official Core Data story. As far as I know, there is still isn’t one. Meanwhile, Drew McCormack built the Ensembles framework, which fixes just about all the problems with Apple’s design and works with both CloudKit and Dropbox.
Fast forward to WWDC 2016. When installing the Xcode 8 beta, I noticed that all of the symbols related to iCloud Core Data were marked as deprecated in macOS 10.12 and iOS 10, with the comment “Please see the release notes and Core Data documentation.” Strangely, the Core Data release notes and What’s New in macOS 10.12 documents make no mention of this. What’s New in iOS 10 simply says that “Several
NSPersistentStoreCoordinator symbols related to ubiquitous content” have been deprecated.
I asked on Twitter what was up, and no one seemed to know. No one had anything nice to say about iCloud Core Data, either, though no doubt many developers still rely on it. I hoped that all would be explained in today’s WWDC Session 242: What’s New in Core Data. Alas, reports are that absolutely nothing was said about iCloud in the session. A key technology that underpins apps is (apparently) to be removed, and Apple didn’t tell anyone at its own developer conference. In my view, this is shameful. The issue is more acute than with a normal deprecation because the APIs rely on cloud services, which could conceivably stop working even for older OS versions where they are not deprecated.
It seems clear that the way forward is Ensembles, unless you want to write your own sync engine or wait for Apple to announce one. I hope that the deprecation will spur more of the community to coalesce around Ensembles.
On a more positive note, it looks like there are a lot of great developments in Core Data this year, including the integration of a mogenerator-like tool into Xcode and, apparently, the end of
NSObjectInaccessibleException, which doesn’t play well with Swift.
Update (2016-06-18): Drew McCormack:
If you move to Ensembles now, you not only get the usual support, documentation, and source code, you also get it all at half the standard price. The sale will continue until macOS Sierra is released later this year.
Update (2016-06-19): See the comments on Hacker News.
Update (2016-06-22): Apple’s Ben Trumbull:
Apps will continue to work for the foreseeable future. Aside from the deprecation warnings, there are no changes to or removal of the functionality in iOS 10. We don’t have any specific time line to announce now, but traditionally deprecated symbols on our platform remain functional for a considerable period of time before removal.
Only the client Core Data iCloud API symbols are deprecated. Core Data with iCloud is built on top of the iCloud Drive service. The service pieces are not effected in any way and will continue to work. If and when the deprecated APIs are disabled in some future OS version, applications running on iOS 9 or 10 will continue to work.
However, App Store Review Guidelines say that apps cannot use deprecated technologies.
Update (2016-06-27): Daniel Pasco:
Last time I dove in to iCloud I lost a year of schedule and an evangelist eventually called me a masochist for continuing to try.
Apple File System Guide (Hacker News):
Apple File System is a new, modern file system for iOS, OS X, tvOS and watchOS. It is optimized for Flash/SSD storage and features strong encryption, copy-on-write metadata, space sharing, cloning for files and directories, snapshots, fast directory sizing, atomic safe-save primitives, and improved file system fundamentals.
A Developer Preview of Apple File System is included in OS X 10.12. The APFS on-disk volume format is pre-release and subject to change. Apple plans to document and publish the APFS volume format when Apple File System is released in 2017.
Lee Hutchinson (Slashdot):
APFS also adds a copy-on-write metadata scheme that Apple calls “Crash Protection,” which aims to ensure that file system commits and writes to the file system journal stay in sync even if something happens during the write—like if the system loses power.
Snapshots and clones both are going to be available in APFS. Snapshots let you throw off a read-only instance of a file system at any given point in time; as the file system’s state diverges away from the snapshot, the changed blocks are saved as part of the snapshot. This is similar in concept to Microsoft’s shadow copies, and it’s an incredibly handy feature. There are obviously huge implications here in how Time Machine works—a true file system set of snapshots could totally replace the kludgy and aging mechanism of hard links that Time Machine builds and maintains.
Clones differ from snapshots in that clones are writable instead of read-only. According to the documentation, APFS can create file or directory clones—and like a proper next-generation file system, it does so instantly, rather than having to wait for data to be copied. A cloned file or directory stores the changes made between it and the original objects, giving you a writable, editable, point-in-time copy of a file or a directory. As the documentation points out, this is an easy way to create document revisions or do versioning of anything you might want to track.
Also interesting is the concept of “space sharing,” where multiple volumes can be created out of the same chunk of underlying physical space. This sounds on first glance a lot like enterprise-style thin provisioning, where you can do things like create four 1TB volumes on a single 1TB disk, and each volume grows as space is added to it. You can add physical storage to keep up with the volume’s growth without having to resize the logical volume.
Although APFS does checksum metadata blocks it does not do anything to provide resilience for data blocks. That is a huge omission in a modern filesystem, a point I tried to politely but forcefully make in the File System Lab directly to a responsible engineer. I got the feeling that the APFS team is divided on the necessity of this feature and some people on the team would appreciate some ammo to help win the argument internally. I would encourage anyone who agrees to file radars ASAP requesting this feature.
I did get confirmation that Apple intends to provide an open specification in 2017 when the design is finalized. They also emphasized that the data structures are designed to be extended in backward and forward compatible ways so things like parity checks should be easily implemented even if they don’t make the first release.
I love the sense of humor the low-level engineers have, as demonstrated by the
Aymeric Barthe (via Benjamin Encz):
When it was first released, HFS+ did not support hard links, journaling, extended attributes, hot files, and online defragmentation. These features were gradually added with subsequent releases of Mac OS X. But they are basically hacked to death, which leads to a complicated, slow and not so reliable implementation.
Finally there is Bit Rot. Over time data stored on spinning hard disks or SSDs degrade and become incorrect. […] HFS+ lost a total of 28 files over the course of 6 years.
Adam Leventhal (via Hacker News):
By the next WWDC it seemed that Sun had been forgiven. ZFS was featured in the keynotes, it was on the developer disc handed out to attendees, and it was even mentioned on the Mac OS X Server website. Apple had been working on their port since 2006 and now it was functional enough to be put on full display. I took it for a spin myself; it was really real. The feature that everyone wanted (but most couldn’t say why) was coming!
I’m told by folks in Apple at the time that certain leads and managers preferred to build their own rather adopting external technology—even technology that was best of breed. They pitched their own project, an Apple project, that would bring modern filesystem technologies to Mac OS X. The design center for ZFS was servers, not laptops—and certainly not phones, tablets, and watches—his argument was likely that it would be better to start from scratch than adapt ZFS. Combined with the uncertainty above and, I’m told, no shortage of political savvy their arguments carried the day. Licensing FUD was thrown into the mix; even today folks at Apple see the ZFS license as nefarious and toxic in some way whereas the DTrace license works just fine for them. Note that both use the same license with the same grants and same restrictions. Maybe the technical arguments really were overwhelming (note however that ZFS was working internally on the iPhone), and maybe the risks really were insurmountable. I obviously have my own opinions, and think this was a great missed opportunity for the industry, but I never had the burden of weighing the totality of the facts and deciding. Nevertheless Apple put an end to its ZFS work; Apple’s from-scratch filesystem efforts were underway.
In the 7 years since ZFS development halted at Apple, they’ve worked on a variety of improvements in HFS and Core Storage, and hacked at at least two replacements for HFS that didn’t make it out the door. This week Apple announced their new filesystem, APFS, after 2 years in development. It’s not done; some features are still in development, and they’ve announced the ambitious goal of rolling it out to laptop, phone, watch, and tv within the next 18 months. At Sun we started ZFS in 2001. It shipped in 2005 and that was really the starting line, not the finish line.
Previously: ZFS, The Loss of ZFS.
See also: WWDC Session 701: Introducing Apple File System, ZFS data integrity explained, Trust, But Verify, Belt and Suspenders, Computational Skeuomorphism.
Update (2016-06-20): Adam Leventhal has written a series of posts based on his talks with Apple engineers Dominic Giampaolo and Eric Tamura at WWDC. Overview (Hacker News):
APFS, the Apple File System, was itself started in 2014 with Dominic as its lead engineer. It’s a stand-alone, from-scratch implementation (an earlier version of this post noted a dependency on Core Storage, but Dominic set me straight). I asked him about looking for inspiration in other modern file systems […] he was aware of them, but didn’t delve too deeply for fear, he said, of tainting himself.
Encryption, Snapshots, and Backup:
ZFS includes snapshots and serialization mechanisms that make it efficient to backup file systems or transfer file systems to a remote location. Will APFS work like that? Probably not[…]
Space sharing is more like an operational detail than a game changing feature. You can think of it like special folders with snapshot and encryption controls…
Space Efficiency and Clones:
Clones open the door for potential confusion. While copying a file may take up no space, so too deleting a file may free no space. Imagine trying to free space on your system, and needing to hunt down the last clone of a large file to actually get your space back.
Cloning fixes an important problem with hard links. The issue with hard links is that some applications will write “into” hard links, effectively changing both “copies” of the file, and other applications will “break” the link (copy on write).
It’s also worth pointing out that hard links typically share the same metadata (such as file permissions). APFS clones assumedly would be less strict about this (e.g., allow two clones of the same data have different file permissions).
Apple controls the full stack including the SSD, FTL, and file system; they could have built something differentiated, optimizing this components to work together. What APFS does, however, is simply write in patterns known to be more easily handled by NAND.
APFS also focuses on latency; Apple’s number one goal is to avoid the beachball of doom. APFS addresses this with I/O QoS (quality of service) to prioritize accesses that are immediately visible to the user over background activity that doesn’t have the same time-constraints.
APFS removes the most common way of a user achieving local data redundancy: copying files. A copied file in APFS actually creates a lightweight clone with no duplicated data. Corruption of the underlying device would mean that both “copies” were damaged whereas with full copies localized data corruption would affect just one.
APFS checksums its own metadata but not user data. The justification for checksumming metadata is strong: there’s relatively not much of it (so the checksums don’t consume much storage) and losing metadata can cast a potentially huge shadow of data loss. If, for example, metadata for a top level directory is corrupted then potentially all data on the disk could be rendered inaccessible. ZFS duplicates metadata (and triple duplicates top-level metadata) for exactly this reason.
Explicitly not checksumming user data is a little more interesting. […] Apple engineers I spoke with claimed that bit rot was not a problem for users of their devices, but if your software can’t detect errors then you have no idea how your devices really perform in the field. ZFS has found data corruption on multi-million dollar storage arrays; I would be surprised if it didn’t find errors coming from TLC (i.e. the cheapest) NAND chips in some of Apple’s devices.
This is disappointing. EagleFiler has detected lots of bit rot for me over the years, including on SSDs, and I’ve seen lots of unviewable old JPEG files.
Those are great goals that will benefit all Apple users, and based on the WWDC demos APFS seems to be on track (though the macOS Sierra beta isn’t quite as far along).
Update (2016-06-27): See also: TidBITS, comments on ArsTechnica, comments on Hacker News, Accidental Tech Podcast.
Git (via Hacker News):
If you’ve used Git, you’ve probably looked at a lot of diffs. Most of the time the diff shows exactly what you did: changed some lines, added some new ones, or took some away. But because Git generates the diff only from seeing the “before” and “after” states of your files, sometimes the way it shows the changes can be pretty confusing.
The author probably didn’t write the loop as two out-of-order halves. But because the outer lines of the old and new loops are the same, it’s equally valid to attribute the lines either way (it’s tempting to say that the problem can be solved by always starting the added lines at the top, but that only fixes this case; you’d have the opposite problem if the new loop were added after the old).
In 2.9, Git’s diff engine learned a new heuristic: it tries to keep hunk boundaries at blank lines, shifting the hunk “up” whenever the bottom of the hunk matches the bottom of the preceding context, until we hit a blank line.
It’s experimental, so you have to enable
diff.compactionHeuristic with git config. Xcode 7.3.1 comes with Git 2.7.4, and the Xcode 8 beta comes with 2.8.1.
The removal of color from the user interface played a significant role in meeting these goals. Color is now exclusively reserved for the indication of status, both for user interface elements, where blue is used consistently to include that something is on/selected, and for the version control status of user content (e.g. file status, text differences).
Cornerstone 3 implements sandboxing in order that we can continue to offer Cornerstone to Mac App Store customers. […] The implementation of sandboxing in Cornerstone was extremely challenging. While many other developers have either given up or taken the opportunity to remove their apps from the Mac App Store citing the difficulty of implementing sandboxing, we have invested heavily into re-engineering significant parts of Cornerstone to not just work within the confines of sandboxing, but to embrace it.
External compare tools can no longer be run directly from Cornerstone. Instead, the compare tool plugin for your tool of choice must be installed to Cornerstone’s application script folder using the new Compare Tools window (see the Compare Tools… command in the Cornerstone menu).
Looks like a huge update. They also sell direct, which is the only way to get the upgrade discount.
There were rumors that Connect was going to be deleted, but apparently Apple is going to try to make it work. It’s is a good idea for Connect to be in the For You section, instead of having its own tab.
Switch to Browse to see what’s new, and what’s not.
Again, there are text tabs in the window, rather than using a menu. New Music shows what’s new on Apple Music, Curated Playlists is what it says, then you see Top Charts, if you want to know what’s popular, and Genres takes you to a rather boring page of text links from which you can access a number of genres. The options within each genre haven’t changed, but the fonts have.
Here are a few screenshot of Apple Music on iOS; as you can see, they essentially reproduce the same elements as iTunes, just in a vertical layout. One problem I see is the size of the artwork for playlists and albums; it should be smaller, so you can see a bit more content.
Thursday, June 16, 2016 [Tweets]
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.
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.
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.
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.
It’s like modern Apple though. Ask yourself, who does this help?
I have asked, and can’t think of anybody but deep-pocketed developers with non-definitive search results.
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.
Feels good to decouple the two, let MAS have its own value proposition apart from CloudKit, vice-versa.
Basically, they remove all the reasons for MAS (together with paying for direct Mac apps using Apple Pay).
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.
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
/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
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
~/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.
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.
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.
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.
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.
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.
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.
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.
That’s a lot of money but it seems like an obvious fit. Also, Nadella was probably tired of getting all those LinkedIn emails.
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?
Wednesday, June 15, 2016 [Tweets]
Previously: Pre-WWDC Thoughts, WWDC 2015 Links.
Sunday, June 12, 2016 [Tweets]
Jacob Kastrenakes (via Hamish Sanderson):
That syncing tool has now been moved out of the core Facebook app and into the photo app Moments. Facebook made it clear that this would happen — and in fact it happened months back, seemingly without much pushback. What Facebook was less clear about was what would happen to photos that had previously been synced.
At the time, Facebook mentioned that people would be given the chance to download their pictures in a zip file if they didn’t want to move over to Moments. Now it’s clear that offering is because Facebook intends to completely delete synced photos if people don’t download this new app.
Mark Wilson (via Slashdot):
This has understandably led to panic installations of Moments as people sought to protect the photos that have been automatically synchronized from their phone. It’s important to note that it is only these synced photos that are at risk, but it’s clear that there is an element of confusion about what Facebook is planning to delete. The email the company is sending out to users[…] The email is very poorly worded, and almost has the feeling of spam to it.
Kate Conger (via John Gruber, Slashdot):
Even though several huge data breaches have recently exposed hundreds of millions of social media login credentials online, users aren’t re-setting their passwords — which means you’ll probably continue to see celebrities’ social media accounts getting hijacked.
After regaining control of his Twitter account, Mckesson explained that the hacker or hackers were able to take over by convincing Verizon to reset his SIM. With the SIM reset, the person responsible was able to receive text messages intended for Mckesson and therefore bypass the two-factor authentication the activist used to keep his account secure.
Passwords for tens of millions of Twitter accounts appeared online for sale this week, following the hacks of accounts belonging to Katy Perry, Ev Williams, Mark Zuckerberg, Drake and others. Although it’s possible that some of their passwords were included in the auctioned database, it’s more likely that their accounts were compromised because they reused passwords from other breached websites like LinkedIn, Myspace and Tumblr.
With the last four digits of Mckesson’s Social Security number, they were able to gain full access to his Verizon account and changed the SIM, which redirected texts to a different device.
The hackers didn’t even need his account’s passwords. They could simply reset passwords to trigger two-factor authentication.
In a blog post, the FTC’s Chief Technologist Lorrie Cranor described how you can add an extra layer of security with your mobile carrier.
Without the proper carrier settings, two-factor is actually less secure than only using a password. AT&T customers should enable the “Extra security” option so that accessing the account always requires a 4-digit PIN other than the SSN.
Previously: Seven Hundred Million.
Update (2016-06-12): Glenn Fleishman:
Companies retain SMS as an option because of the customer-support burden: it’s easier to get someone to type in a code sent as a text message than to download, install, configure, and use an authenticator app. But you would think the time is ripe for companies to allow expert users to disable SMS as a backup option, especially since many sites pair turning on 2FA with creating a set of backup, one-time use passwords intended to restore access if one loses access to the authentication app that can generate the appropriate code.