Sunday, July 5, 2015 [Tweets]
Airplane Mode turns off all internet functions, phone calls, and texts. Prior to iOS 8.3, Airplane Mode also disabled the GPS in your iPhone/iPad, which crippled most of Gaia GPS. Now, with the latest iOS updates, you can use Airplane Mode, and Gaia GPS will be able to plot you on the map, and record your trip.
Presumably the GPS does not perform as well without access to cellular towers or Wi-Fi. But this could potentially save a lot of battery life when you’re in an area with poor cell service. Plus, it would let you track your flight process while on an airplane, if you had the maps preloaded.
iOS comes with a selection of fonts that cover the major writing systems of the world. Some apps, however, need to install additional fonts for system-wide use. […] This article describes how such apps can package and install fonts, based on my experience bundling the Ubud font with the Balinese Font and Keyboard app. Note that this is about system-wide use – if you need to bundle a font just for use within your own app, Chris Ching has a tutorial for that.
For some parts of the Unicode character set WebKit now looks for fallback fonts, for other parts it doesn’t (Balinese was one of the lucky scripts). Recent code changes in WebKit indicate that this will finally be completely fixed in iOS 9.
While support for third-party keyboards was highlighted as a new feature in iOS 8, support for third-party fonts received much less attention. This is probably because the support that exists was primarily targeted at enterprise customers: Fonts for use across apps are packaged in configuration profiles, which otherwise serve to configure virtual private networks, disable games and unsafe web sites, locate network printers, and do other things that matter in corporate environments.
[Apple] Configurator creates and uses a self-signed certificate, which iOS doesn’t trust, so you get the same number of warnings, just saying “Not Verified” instead of “Not Signed”. […] I ended up buying a COMODO code signing certificate from KSoftware, which cost US$95 and quite some time because their support for Macs is a bit flaky.
Installed fonts do not get updated automatically. When the user installs a new version of your app that includes a new version of the font, you likely have to remind the user to re-install the font.
So I guess Font/DA Mover is no longer the hard way to install fonts.
I have long had Settings ‣ iTunes & App Store ‣ Automatic Downloads ‣ Updates enabled but Use Cellular Data disabled. I thought the latter would protect me from unreliable cellular connections and wasting bandwidth. Unfortunately, I did not account for unreliable hotel Wi-Fi or what I consider to be an OS bug.
On a recent trip, iOS started downloading an update to Editorial but apparently couldn’t finish the process. This would be OK except that it left the app in an incomplete state where the home screen showed that it was in the process of updating, but the app would not launch. So I was unable to access my important notes. (Other Dropbox text editors would have worked but didn’t have the files cached on the phone.)
Previously: Downside of Automatic App Updating.
Friday, July 3, 2015 [Tweets]
My experience with Siri keeps changing. I’m pleased with the recent change where you no longer have to confirm before a reminder is added. Instead, you just tap Remove if Siri got it wrong. There’s still no good way to edit if Siri got it partially right, though. And sometimes Siri is repeatedly so far off that it’s not even enough to jog my memory; I wish I had just stopped to type.
It is maddening how many times I will see that the phone has cell service and dictate my reminder, only to have Siri spin seemingly forever or complain that it doesn’t have an Internet connection. Couldn’t it have told me that sooner? Or recorded what I’d said so that it could be replayed when a connection becomes available? Since Siri requires a connection, it shouldn’t even play the “start talking” prompt unless it knows that it can reach the server.
You can now store your encrypted Arq backups in your own Amazon Cloud Drive account!
Amazon Cloud Drive includes unlimited storage for $59.99/year, so you can back up everything. Amazon provides a web interface to upload and download files, but Arq uses its API to upload directly to the cloud.
Previously: Amazon Cloud Drive.
By far the coolest of these improvements is the use of Apple’s facial recognition APIs to improve image previews. What does that mean exactly? It means that as Twitterrific displays media thumbnails in the timeline (pictures, videos, etc), the app tries to detect faces and frame the thumbnail so faces are always showing. In short, if Twitterrific sees a face in a tweet, it tries to make sure you see it too!
A lobby that wants you to believe that one weird trick will make your codebase better, replacing the cargo-cult Agile practices with equivalently useless cargo-cult functionalist practices.
As we’ve established, most types (say, 90%) can implement funcs in a non-mutating way. But to quote another Zawinski law, “Everybody uses a different 10%”. […] Similarly, for every type that is sufficiently large, it conforms to some non-mutating protocol with a mutating implementation. […] Now. How are we going to solve this problem? Well, the mutating inner class.
It is not wrong to wrap a class in a struct. This is how Swift.Array works under the hood. […] The difference is, A) they have been really clever about hiding the inner class, which involves a lot of code and neat tricks that you can learn more about in the WWDC session (e.g., this is an advanced topic, that you should not sprinkle liberally throughout your codebase where the muggles will see it) and B) there is nothing fundamentally classful about arrays. Arrays are, from a certain point of view, a kind of value. So it makes sense for them to be a value type.
The moral of this story is that immutable, pure functional programming does not always work even in the literal textbook examples. A mutating implementation of the Sieve is both simpler and faster, and far from helping, functional programming has actually hindered the exercise of writing fast, maintainable code.
Finally, the official Apple guidance concludes with this dire warning:
In all other cases, define a class, and create instances of that class to be managed and passed by reference. In practice, this means that most custom data constructs should be classes, not structures.
Update (2015-07-05): David Owens II:
The fundamental problem I find with the piece is that it creates a false selection of choices to the problem statement posed while misrepresenting much of the advice about choosing when to use value types. I think it also confuses the purpose of the proposed “inner class device”.
The entire purpose of the “inner class” is to provide value semantics while maintaining efficiency of implementation. In addition to that, if some of the quoted advice in the article had been followed with regards to struct usage, a different conclusion would have presented itself.
I agree with you that inner mutability “feels” wrong in the
CanSend example. But the suggestion that inner mutability should never ever be used is wrong, because of
Swift.Array. So we need some rule to distinguish when inner-mutability-with-structs is bad from when it is okay. If the rule was “never do any mutation inside a struct” then we would not have value-typed-arrays to begin with.
(In fact, we didn’t have value-typed-arrays to begin with. I have a serious theory that it was exactly the rigid application of “never have inner mutation” inside Swift that initially led to the silly behavior. Recall that in early betas, the value/reference behavior of arrays used to hinge on whether or not the operation caused a resize--which is exactly those cases in which the array implementation needed to mutate the free block chain.)
David Owens II:
I think it’s safe to say that using inner classes to simply break the mutability contract of a protocol is a poor reason that’s going to lead to all sorts of bad behavior (like the original arrays in Swift).
I’m saying that I think that line is somewhere near the area of, “I really want to present a value-semantic type, but the performance is going to suck if I do, so let’s create an implementation with a backing inner class”.
Tuesday, June 30, 2015 [Tweets]
If I estimate the number of iOS apps in the App Store, and get the difference between the estimate and the actual number, that difference will be larger than the number of successful apps.
(I define successful as a good-faith “makes enough of a profit to make it worth continuing to work on the app.” Most apps fail to make a profit at all, of course.)
I haven’t done an actual study. But do any developers doubt that I’m right? And when developers think this way, they take their app ideas and toss ’em aside.
Crushingly, maddeningly, this is very correct.
Update (2015-07-03): Allen Pike:
However, when expressing frustration with the current economics of the App Store, we need to consider the effect of this mass supply of enthusiastic, creative developers. As it gets ever easier to write apps, and we’re more able to express our creativity by building apps, the market suffers more from the economic problems of other creative fields.
But the bottom line is that indie development for iOS and the App Store just hasn’t worked out the way we thought it would. We thought — and hoped — it would be like the indie Mac app market, only bigger. But it’s not like that at all.
I’ve long felt that we as a community let our enthusiasm for building something we love and stories of days past blind us to a simple fact that other industries realized long ago: being independent is hard and many of us that try will not succeed.
What we don’t always consider is that the customers looking to buy software for Mac were already paying a premium for hardware (remember when the Apple Tax was a real thing?), so we had a self-selected audience of customers willing to pay for premium goods. Mac devs didn’t yet have to appeal to the mass-market cost-obsessed Dell users.
They were willing to pay a premium for hardware because it came with the promise of every detail being obsessed over, and that appealed to those kinds of people. Customers hence expected the same attention to detail from their software. Back then they weren’t overwhelmed with choice, so new apps with this focus on quality were something to talk about.
The problem is that people aren’t paying for apps because people don’t value apps, generally speaking (I’ve written about this before, too).
What I am saying is if you want a sustainable business, you’ve got to provide value for people. Your app needs to be worth people paying enough money that you can keep your lights on.
We developers need to get over it and stop blaming the App Store for our business troubles, because when it comes down to it, the App Store has only two purposes: credit card processing and software delivery. That’s it. Yeah, I know the App Store was originally sold to developers as a marketing channel, but it hasn’t been that for many years.
This is true, but I think the reason people are tempted to blame the store is the sense that it doesn’t have to be this bad. People don’t expect it to be easy, but it’s frustrating that Apple has stacked the deck against the kinds of apps we want to see. There is no obvious reason to do this, and Apple has not been forthcoming about why it is doing so, even as it apparently does not like the results. Yet we assume this is purposeful because there has been no change of course in six years. As Simmons writes:
I’d add, though, that each market has a shape, and the shape of the iOS App Store is in Apple’s control. They can’t control the behavior of people, but the shape of the market has an impact.
There’s no silver bullet, but there are numerous good ideas that, taken together, could make a significant difference.
However, if you take everything Charles says as truth, it reveals an even more serious problem: the 30% that Apple charges for distributing bits on their truck is outrageous. It’s flat-out wrong to charge such a high percentage if they are providing no value above credit card processing and file hosting.
OS X 10.10.4 shipped today, and as expected based on the developer betas, Discoveryd is gone, replaced by an updated version of good old mDNSresponder. At WWDC, word on the street was that Apple closed over 300 radars with this move. Not dupes — 300 discrete radars.
po $arg1 into the debug area to get the human-readable version of the error (in this case, the nib is invalid) […] Finally, you can add the
po $arg1 command to your Exception Breakpoint so it’s just automatic.
Whereas, otherwise Swift will crash with no useful information when there’s an uncaught exception.
Nolan Lawson (comments):
I think there is a general feeling among web developers that Safari is lagging behind the other browsers, but when you go to a conference like EdgeConf, it really strikes you just how wide the gap is. All of the APIs I mentioned above are not implemented in Safari, and Apple has shown no public interest in them. When you start browsing caniuse.com, the list goes on and on.
Even when Apple does implement newer APIs, they often do it halfheartedly. To take an example close to my heart, IndexedDB was proposed more than 5 years ago and has been available in IE, Firefox, and Chrome since 2012. Apple, on the other hand, didn’t release IndexedDB until mid-2014, and when they did, they unveiled a bafflingly incompetent implementation that was so bad, it’s been universally derided as unusable. (LocalForage, PouchDB, and YDN-DB, the major IndexedDB wrappers, all ignore Safari’s version and fall back to WebSQL.)
In recent years, Apple’s strategy towards the web can most charitably be described as “benevolent neglect.”
To circle back to IndexedDB again, it was fully implemented by Google well before the Blink fork, and for several years, Apple could have just flipped a bit in their build script to include Google’s implementation, but instead they decided to waffle for a few years and then replace it with their own broken version. There’s no guarantee they wouldn’t do the same thing for other outside contributions.
I think the analogy is very clear. If you want to code like it’s 2000, supporting IE6 is easy, because IE6 is a very good 2000 browser. If you want to code like it’s 2010, supporting Safari is easy, because Safari is a very good 2010 browser. But in both cases, if you want to use any new features that have been standardized and are supported by other browsers, you’re fucked.
The main difference I see is that IE6 didn’t get any updates at all. Safari gets updates, but many new features are missing or broken.
Another difference is that MS never blocked you from installing a better browser, but Apple does that on iOS. That policy is becoming increasingly ridiculous…
Update (2015-07-03): Nolan Lawson:
Looking thru public-webapps, I see @ryosukeniwa from Apple has been super active on WebComponents/ShadowDOM. I was dead wrong! Apologies. :(
Thursday, June 25, 2015 [Tweets]
OS X El Capitan Developer Beta 2 Release Notes:
MapKit APIs can now be used by developers in apps that are distributed outside of the App Store.
Via Rosyna Keller, who asks:
Which public OS X APIs are still restricted to Mac App Store apps? GameKit, iCloud/CloudKit, Remote Push Notifications, what else?
Good news, although it won’t help those deploying on earlier versions of Mac OS X. I hope that apps like Fantastical and Lightroom will continue to offer integrated Google Maps, which I find to be more accurate and easier to read.
Update (2015-06-25): Marcel Weiher:
I am at a complete loss … I think it’s the first time since introduction of the stores that the screws have been loosened.
Tasos Lazarides (via Paul Haddad):
It’s looking like Apple has pulled everything from the App Store that features a Confederate flag, regardless of context. The reasoning Apple is sending developers is “…because it includes images of the confederate flag used in offensive and mean-spirited ways.” We just spoke with Andrew from HexWar Games, who have released many historical strategy games. He insists, “We’re in no way sympathetic to the use of the flag in an offensive way, we used it purely because historically that was the flag that was used at the time.”
Apple has sent a removal letter to affected developers to inform them that their app does not comply with Section 19.1 of the App Store Review Guidelines.
“19.1 Apps containing references or commentary about a religious, cultural or ethnic group that are defamatory, offensive, mean-spirited or likely to expose the targeted group to harm or violence will be rejected.”
The flag has been increasingly under fire in the wake of the racially motivated church shooting in Charleston, South Carolina, and retailers such as Amazon, eBay, and Walmart have withdrawn sales of items depicting it. However, some say that Apple has gone too far, since the ban also includes a number of Civil War games that used the flag in a historical context, some of which were used by educators.
It has never made sense to me why Apple bans apps for certain kinds of content yet continues to sell books, movies, and music that include that same content.
Update (2015-06-26): Kwame Opam:
Civil War games with educational or historical value won’t be banned, says Apple.
However, the statement might make matters more confusing for some developers, as Apple appears to be removing all games that depict the flag.
At WWDC when Apple unveiled iOS 9 one of the features they highlighted was a reduction in the upgrade free space requirement from 4.6GB to 1.3GB.
66% of my customers on eligible devices have at least 1.3GB of free space. This compares to just 37% of users who would have immediately had sufficient space at the old iOS 8 requirement.
iOS 9 is implementing some changes to make things easier on owners of 8GB and 16GB iPhones and iPads. We’ve already taken a look at App Thinning, a collection of technologies that will reduce the amount of space downloaded apps take up.
Today, the company sent out its first update for the iOS 9 developer beta, and iOS developer Kaleb Butt noticed yet another feature—if you don’t have the required free space, the operating system will offer to delete apps to make room for the update. It will then automatically re-download them when the update is complete.
Deleting an app from your phone or tablet normally takes all of that app’s saved data and settings with it. Presumably, Apple has either devised a way to keep that from happening, or it’s using iCloud to backup and restore your data along with the app.
For the first time since FogBugz’ creation some 15 years ago, it contained 0 lines of VBScript or Wasabi code. The ‘End‘ of an era.
For those of you that don’t know, Wasabi was our own in-house .NET compiler. In this post, I’m going give you the background of Wasabi, including why we created it and what it enabled us to do, before giving you the inside scoop on why we’ve now killed it off. In a follow-up post, we’ll talk about some parts of Wasabi that we’ll be open-sourcing.
In 2011, Ted Unangst proposed “Project Soy Sauce”, a combination of .NET Reflector and Perl scripts to turn the Wasabi binary output into nearly-readable C# source code. This time, we finally succeeded, because of Roslyn, the newly open-sourced .NET Compiler Platform.
Building an in-house compiler rarely makes sense. It is much more economical to lean heavily on other people’s work and use standard, open technology. You must be prepared to not only create your own universe but to then nurture it long-term. We weren’t ignorant of this when the project began, but it’s much easier to switch languages at the beginning of a project than halfway through. A homegrown compiler might make sense when trying to port to a new platform, which Wasabi helped us do several times.
In Swift 1.2 you could
@import simd but it wouldn’t do you much good. The compiler has to map the types to intrinsics, support certain alignment requirements and padding, etc. Swift 1.2 didn’t know how to do any of that so vector extensions were basically unusable.
In Swift 2 that has changed. All the types are present and have full operator implementations. They all have handy initializers (vector initialized to a scalar value, a matrix with diagonals set, and so on). They can convert between the C/Objective-C types quite easily. They have full operator support, including between types so you can multiply a vector and a matrix with wild abandon[…]
Looking at the SIMD results we can see there may still be a branch somewhere but it isn’t nearly as expensive. We also see that SIMD is faster all cases and in the worst-case scenario it’s three times as fast.
Tuesday, June 23, 2015 [Tweets]
Brian Webster (tweet):
For users enrolled in the OS X beta program, the system adds a “Send <appname> Feedback” menu item to the Help menu of all apps on the system, even third party apps. Selecting this menu item opens Apple’s feedback assistant, which allows users to send bug reports etc. on the OS X beta.
I have had multiple reports from users who used this menu item in one of my apps and were confused that I had never received the information they had submitted. It is not at all clear to users that feedback sent by selecting that menu item is going to Apple, and not the app developer. This can cause support issues and poor customer sat for third party developers. This feedback menu item should only be displayed for Apple’s own applications, and not third party ones.
Over the last few days, several users let me know they were unable to download our apps from the Mac App Store. They reported that they were receiving this error message when trying to purchase or update:
App Store Error: Failed to verify the preflight file. It is not signed by Apple.
In theory, Apple (in exchange for their 30% cut of our revenue) should be helping these users solve such problems. But based on what I’ve heard, that’s not usually the case, so they end up writing to me. After a bit of web searching, I found the cause and solution to the problem: Keychain Access.
Omer Barnir (via Peter Steinberger):
When rows of a table are updated/deleted indirectly as a result of a foreign key definition on the table, triggers on that table are not executed as required[…]
There is no clean workaround that could achieve this functionality. I appreciate the work that the Mysql has put into this wonderful DBMS, but why not just go a little bit further to make this a complete product? I would really, really appreciate if someone can address this problem, which frankly, is a bug because this makes Mysql non-ACID compliant.
Lightroom CC 2015.1 and Lightroom 6.1 are now available on Adobe.com. The goal of this release is to provide additional camera raw support, lens profile support and address bugs that were introduced in previous releases of Lightroom.
Via Agen G. N. Schmitz:
Lightroom CC 2015.1 receives the new Dehaze feature for removing haze and fog from pictures (or, conversely, adding more haze to a photo). Additionally, Lightroom CC 2015.1 brings local white and black adjustment sliders to the Gradient Filter, Radial Filter, and Local adjustment brush tools, improving the capability to fine-tune tonality near the brightest and darkest parts of the picture. While it doesn’t gain the added features, Lightroom 6.1 does receive the same bug fixes as Lightroom CC 2015.1, including a resolution to a slow start that would devolve into an unending blue spinning wheel with any attempt to click within the app.
The direct link to download the new version is here. It does seem to fix a flicker bug that I saw when the graphics processor was enabled. However, I’m disappointed that the standalone version doesn’t get the same new features as the Creative Cloud version. I paid $149 just last month and am not getting the features, whereas with the $10/month plan I would.
Lightroom 6.x will continue to receive the same level of updates as did its predecessors, (Lightroom Versions 1-5) which included new camera support, new lens support, and bug fixes. Nothing has changed with regard to how Lightroom, in the Perpetual license, receives its updates. Subscribers of Lightroom CC will receive the same level of updates as the Lightroom Perpetual license holders however, in addition Lightroom CC will receive new features as they are released.
There is no plan to add any new features to the Lightroom 6.x cycle.
This was not clear to me when purchasing the standalone version. Indeed, Adobe’s own FAQ says:
You can purchase a perpetual download version of Lightroom 6 on Adobe.com here. Note, the perpetual license doesn’t provide access to Lightroom mobile or Lightroom web.
This implies that the only difference is the mobile and cloud features, which I don’t care about. So the standalone version seemed like a good deal given that over the lifetime of the product the Creative Cloud version is about 2–3x the price if you only want Lightroom, not Photoshop.
Update (2015-06-24): There are lots of comments on the Photography Reddit.
Monday, June 22, 2015 [Tweets]
The essence of the best answers was this:
Value should not be
Equatable — the individual structs should be
In the end, I’m still tempted to say the Objective-C version was simpler. And it is, and not just because I’m more familiar with Objective-C. But it’s important to note that it’s not apples-to-apples. In Objective-C I’m creating classes instead of structs, and there’s no support for the == operator.
But I will say this: Objective-C, because it’s less strict with types, is closer to a scripting language than Swift is.
Though Swift does get rid of a bunch of housekeeping — we can use type inference much of the time, we don’t have to create .h files, etc. — it adds its own housekeeping mandated by a stricter type system (and optionals).
Do you use Google Docs, Office 365, iWork for iCloud, or any of a zillion other such Web apps to create and collaborate on documents? Most of us do, at least occasionally. Fine, but do you also have a local copy of those documents? I’ll bet you don’t, and that’s a bad idea.
When a method runs, you want to be sure that it has all the data it needs to work properly, and your code should only execute when that’s the case. Coders solved that in common two ways: pyramids of doom and early returns.
guard solves all 3 of the issues mentioned above:
- Checking for the condition you do want, not the one you don’t. This again is similar to an
assert. If the condition is not met,
else statement is run, which breaks out of the function.
- If the condition passes, the optional variable here is automatically unwrapped for you within the scope that the
guard statement was called – in this case, the
fooGuard(_:) function. This is an important, yet notably strange feature that really makes the
guard statement useful.
- You are checking for bad cases early, making your function more readable and easier to maintain.
In Swift 2, Apple introduced API availability checking. If you set your app’s Deployment Target to a lower iOS release than the base SDK, Xcode will automatically scan every API you use to make sure it’s available in your lowest deployment target version. This information has been in Apple’s API headers for years, but it’s only now being exposed to the compiler. What it means is that if your app compiles, you can be guaranteed it doesn’t call any code that can’t run because of missing APIs.
In that code,
#available is going to check whether we’re on iOS 9 or later, or any other unknown platforms like watchOS – that’s the * at the end, and it’s required. And that’s it: all the code you’ll put in place of "// use UIStackView" effectively has elevated rights to use iOS 9.0-only technology, whether that’s classes, methods or enums.
Natasha Murashev on unwrapping multiple optionals using pattern matching:
I was at first frustrated by the use of
? to indicate that the value does exist (especially since I associate it with the idea of optionals, where the value may or may not exist), but I have to admit that this example is very clear to understand. And I definitely like it as a much better alternative to the clunky .Some(username) syntax.
Inspired by Mike Ash’s tweet, I tried generating JSON dictionaries in Swift by using the new reflection features.
We can provide a default implementation by extending the protocol. This default implementation reflects a value, and loops over the children, recursively serializing them as well. If the type doesn’t have any children, we assume it’s a primitive (e.g. a String or an Int) and don’t serialize it.
The terrible world of
CFunctionPointer is gone in Swift 2. Instead, Swift function types have trifurcated into variants. Any Swift function type can optionally be annotated with a
@convention specifier which says what kind of function it is. The
swift convention is the default and indicates a normal Swift function. The
block convention indicates an Objective-C block type. These were automatically bridged, and still are, but now the typing is more explicit. Finally, the
c convention indicates a C function pointer. Function types annotated with
@convention(c) still behave mostly normally, so you can call them and pass them as usual.
The idea behind
for…in filtering is that now you can do filters inline vs in your
Note that you can use the pattern matching with “if case” in combination with the
for…in filtering for some even more advanced filtering!
I’d still like to see list and dictionary comprehensions.
In an HN sub-thread sparked by my ModernWeb.tw slides, I concurred with Patrick Walton on analogies between browsers and the Unix kernel, JS and C. One does not get to write kernel code in any language, at least not yet. Elsewhere in that sub-thread the analogue of JS was identified as architecture-specific assembly code, where the CPU architecture is fixed by physical reality, while software is written in virtual languages compiled to machine code, or run through interpreters.
In any event, whether analogous to C or assembly, JS has had a lock on the “kernel” of the client side. Web “userland code”, in contrast, can be written in a great many languages. Adding a second (bytecode) syntax has looked like a “now you have two problems” loss, against the alternative of one syntax. Until now.
It’s by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let’s say. Today I’m pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web. As reflected in the high-level goals, a central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version run efficiently on current browsers using a client-side polyfill. As demonstrated, the polyfill can leverage asm.js to get great performance. For existing Emscripten/asm.js users, targeting WebAssembly will be as easy as flipping a flag. Thus, it is natural to view WebAssembly as the next evolutionary step of asm.js (a step many have requested and anticipated).
I write this to explain why I’ll be holding back my album, 1989, from the new streaming service, Apple Music.
I’m sure you are aware that Apple Music will be offering a free 3 month trial to anyone who signs up for the service. I’m not sure you know that Apple Music will not be paying writers, producers, or artists for those three months.
This is not about me. Thankfully I am on my fifth album and can support myself, my band, crew, and entire management team by playing live shows. This is about the new artist or band that has just released their first single and will not be paid for its success. This is about the young songwriter who just got his or her first cut and thought that the royalties from that would get them out of debt.
These are the echoed sentiments of every artist, writer and producer in my social circles who are afraid to speak up publicly because we admire and respect Apple so much.
Also raises the question of just how many other top-shelf music will not be available on Apple Music when it launches. After the WWDC keynote, I simply could not get a straight answer from anyone at Apple about just how much of the iTunes Music library will be available on Apple Music when it launches. Part of that might be that they’re still negotiating with some labels and top-shelf acts, but I can’t help but suspect part of it is that they know they’re not going to have everything, and they don’t want to talk about that.
Peter Kafka (via John Gruber):
In the U.S., Apple will pay music owners 71.5 percent of Apple Music’s subscription revenue. Outside the U.S., the number will fluctuate, but will average around 73 percent, he told Re/code in an interview.
Apple won’t pay music owners anything for the songs that are streamed during Apple Music’s three-month trial period, a bone of contention with music labels during negotiations for the new service. But Kondrk says Apple’s payouts are a few percentage points higher than the industry standard, in part to account for the lengthy trial period; most paid subscription services offer a free one-month trial.
It seems to me with iTunes & App Store, Apple created an incredible opportunity for content creators to be paid fairly, only to squander it.
iTunes raised the price of MP3s from free (pirate) to 99c, likewise the App Store created a way to fairly monetise free Flash games.
But fast forward a few years, and through apathy (or worse) consumers have come to expect apps and music to be free, while Apple profits.
We hear you @taylorswift13 and indie artists. Love, Apple
#AppleMusic will pay artist for streaming, even during customer’s free trial period
Update (2015-06-22): Kirk McElhearn:
Apple doesn’t pay artists or producers. Ms Swift says nothing about record labels, who, other than for the publishing payment, are the ones who collect the money. This distinction is very important when discussing streaming music. All the streaming services try and claim that they pay “artists,” but they absolutely do not.
When an artist gets paid, it’s by their record label. Standard contracts give a recording artist somewhere around 10% of the record label’s income, after expenses, including a producer’s royalty, for their recordings. Streams are already paid very little, and the artists get a fraction of that.
Note that Apple won’t be paying the full per-stream rate during the trial period. Peter Kafka of re/code spoke to Eddy Cue[…]
Second, and this is a much bigger issue, it’s unclear if Apple can actually pay the rights during this trial period and not get targeted by competitors for predatory pricing or anti-competitive behavior.
Charles Perry (tweet):
This debate is important to app developers because, whether we like it or not, digital music has been devalued – just as our digital creations have been. In just a few short years people have gone from paying tens of dollars for an album, to paying 99 cents for a single track, to paying pennies or even nothing to stream an entire library of music. This parallels in a rather frightening way the history of the App Store where, in an even shorter amount of time, mobile software that once sold for tens of dollars now is lucky to sell for 99 cents. Just as the music industry, now including Apple, has moved to an “all-you-can-eat” subscription model to bring down the per title cost of music below that 99 cent threshold, it now doesn’t seem unreasonable that a similar all-you-can-eat subscription model might be used to allow per title pricing of apps to fall below 99 cents as well.
Taylor Swift yells about getting paid for trials, and @cue responds in hours. App developers scream about sustainability for years, nada.
I’m not the first to say it but gosh it’d be nice to get some love for indie developers as well as indie artists.
First off, indie developers used to make ~50% of our revenue by giving discounted upgrades to existing customers. Apple blew this away.
Second off, indie developers used to be able to talk to their customers directly. Now customers leave 1-star reviews when they need support.
Third off, indie developers don’t have any real recourse to deal with bad reviews that are actually customers asking for support.
this was a BRILLIANT pr orchestration.
blogs, articles, etc all over the globe were written about apple music, for free. would have been far more expensive to buy all that airtime than this little scandal.
so taylor swift gets more publicity, apple music is now an established brand name, everyone and their dog knows about their pricing model - holy shit. hats off to the apple team, playing the outrage-piano like no other.
I doubt it was planned, but it does seem to have worked out well for both Apple and Swift.
I’m reminded of the huge success Coke experienced after reintroducing Coca Cola Classic after the disastrous new Coke. When questioned about the whole thing Coke’s president Donald Keough said, “Some critics will say Coca-Cola made a marketing mistake. Some cynics will say that we planned the whole thing. The truth is we are not that dumb, and we are not that smart.”
Update (2015-06-23): Eli Schiff:
Apple’s impulsive response to Swift stands in stark contrast to their treatment of indie app developers, who have been lobbying Apple for almost seven years, requesting Apple reform policies in the App Store to no effect. In particular, Cue’s use of the word “indie” can only be described as a callous slap in the face given the circumstances that indie developers have been facing.
Developer reactions have been mixed: Daniel Jalkut of MarsEdit exclaimed, “Damn, I wish Taylor Swift were also a Mac App Store developer.” Cabel Sasser rightly pointed out that complaints by developers have and will likely continue to be ignored: “As if ANY of us nerds have 1/100000th the public perception pull of a Taylor Swift.”
Developer David Barnard pointed out the utter inconsistency here between music and app development: “Apple is subsidizing a 90 day free trial for Music, but there’s still a rule in the App Review Guidelines prohibiting timed trials for apps.” In other words, musicians complain that they will not get paid—Apple immediately subsidizes them. Developers on the other hand do not even have the option of using that marketing strategy.
Sunday, June 21, 2015 [Tweets]
Adam C. Engst:
There are no settings to prevent iCloud Photo Library from working over cellular, and while I disabled cellular data for the Photos app, that made no difference. I could turn off cellular data in general (and I did once or twice, but that’s a hard thing to remember every time you leave the house), but by the end of the billing period, AT&T had hit me with $30 of overage charges for two $15 blocks of 1 GB of additional data.
This is shockingly poor design on Apple’s part, and I hope to see it fixed in iOS 9. The entire point of iCloud Photo Library is to transfer huge quantities of image data, and it’s disrespectful for Apple not to provide a switch to prevent iCloud Photo Library from chewing through cellular data.
Meanwhile, there are issues with Aperture and Mac OS X 10.11:
Importing RAW files may cause the app to quit unexpectedly.
The Aperture workspace may disappear occasionally. To bring back the workspace, click on the Aperture icon in the dock.
Some Sony RAW images may not appear correctly.
Dismissing certain dialogs may cause the workspace to become unresponsive and require a force quit and relaunch.
Aperture may quit unexpectedly when attempting to print photos. The Photos app can be used to print instead.
Maybe these will be fixed before the release, but Aperture is probably a relatively low priority right now. The downside to Apple’s pace is that the old stuff stops working before the new stuff is fully ready.
Update (2015-06-22): Glenn Fleishman:
I have a pile of emails from readers with import problems, even weeks in and after the micro-update from Apple for Photos. Joe Dodd’s is typical: “I can’t get my iPhoto library to finish moving to photos. It freezes up the entire Mac at 11 to 15 percent completion. The Mac is older, but now I don’t know what to do.”
Unfortunately, this appears to be the new default and unchangeable behavior in Photos. If you select a photo and the Edit > Copy menu is available (which is typically is), Photos automatically downsamples to 1024 pixels maximum in the longest dimension in my test.
During a recent bike adventure I was frustrated that I couldn’t copy coordinates from either Google Map or Apple Map. I think I used to be able to do that - but no more. Compass.app would show coordinates, but I couldn’t copy/paste ’em. Best I could do was a screenshot of what Compass displays.
Jeremy W. Sherman:
Compass does let you copy out the coordinates: Long-press on the coordinates and hit Copy from the floating menu. Don’t tap - that bounces you to Maps.
This is apparently undocumented, and it’s the first I’ve heard of it. So now we have: tap, double-tap, long tap, force touch, Touch ID touch, and Reachability double-touch.
Friday, June 19, 2015 [Tweets]
Apple (via John Gruber):
Get your apps ready with the latest beta versions of the San Francisco fonts for iOS 9, OS X El Capitan, and watchOS 2. To download, sign in with your Apple ID associated with your Apple Developer Program membership.
I’ve only done a little bit of digging into it but, so far, it looks like there are some significant updates and improvements compared to the versions released with WatchKit in November. There’s still no public copy of the rounded variant, however.
Antonio Cavedoni at WWDC (PDF, via Ken Ferry):
Fonts lay at the intersection of design and engineering. Get introduced to typographic principles and how they apply to the San Francisco fonts. Hear what makes this family of fonts unique and how to effectively take advantage of their advanced features. Learn best practices when designing and implementing interfaces with text.
Benjamin Mayo (via Dan Counsell):
Popular podcasting app Instacast for iOS and Mac is shutting down as the founders can no longer fund it or any of Vemedio’s other projects.
Today one of my long time competitors whose product I’ve admired and respected has called it quits. […] I’m very sorry to hear this but the fact is that it’s tough to make money on the App Store. Customers (rightly) demand high quality software which takes time to create, test and support and this requires a business to reach a sustainable income.
One of the first podcast clients on the iPhone, the pioneering player helped propel the medium from its humble roots into a global phenomenon spanning the gamut of genres and subjects. But with the podcast app’s popularity came a catch–along with a hoard of new users, a slew of competing players popped up too, all vying to chip away at Instacast’s sizable audience. Over the course of its lengthy version history, it from paid to free with in-app-purchases and even offered two levels of subscription memberships, but modern clients kept the pressure on until the company announced earlier this week that it had run out of money and was shutting down for good.
I prefer Overcast, but it’s scary that such a popular app would not be profitable.
Finally a [decent] exception model in a modern language, a model where it’s absolutely obvious when to use
do/try/catch. If you miss it, the compiler (precompiler/static analyzer) will tell you. There is no, or very little overhead in using Exceptions in Swift, unlike Java and C# where the runtime must create the exception and unwind the stack and then throw.
My own view is that people are perhaps taking things too seriously. Swift is a very pragmatic language and it’s developing with a set of practical concerns. Mainly the connection to ObjC based Cocoa libraries. Maybe that’s undermining what the language could be. But especially for the next years, the primary purpose of Swift will be to code against Cocoa. For all the problems and limits of Swift exceptions, they do seem a big step up from difficult to read nested if statements. Maybe this decision will limit Swift in the future. But in the present it’ll make most people’s life easier.
This does have one downside: if you add any future values to the enum, which we’re about to do, it will just drop into the default
catch block – you won’t be asked to provide any code for it as would happen with a
David Owens II:
The latest thing I’m running up against in the cumbersomeness of the
do-catch pattern for handling errors. Not only that, I think it promotes the bad exception handling that Java had with people simply writing a single
catch (Exception e) handler.
Swift 2 introduces the
defer keyword, which effectively means “here’s some what I want you to do later, no matter what.” That work can be whatever you want: a single method call closing a file, or 50 lines of code doing some other important clean up work. The important thing is that Swift ensures that it will be run before the current scope is ended.
One of the most powerful features of
defer is that you can stack up multiple deferred pieces of work, and Swift will ensure they all get executed. What’s more, it executes them in reverse order, meaning that the most recently deferred thing gets run first – effectively unwinding a stack.
Nick Lockwood on Brad Larson’s post:
If you look at the examples in that article, the reason why the result enum doesn’t work well for him is that the methods being called are primarily synchronous, and without return values. They aren’t pure functions. […] But does that mean result types are bad? No, they’re pretty awesome for functions that actually return a result that we want to pass to the next function (possibly an unspecified amount of time later). They just aren’t great for handling errors produced by procedures that don’t return anything, and execute sequentially on the same thread, because they must be checked after every call, and that quickly becomes tedious.
try only works in this one situation, with sequential imperative statements. If Brad Larson was working on something like a network library instead of a robot controller, result types would work much better for error propagation than Swift 2’s exceptions, because exception-style errors don’t really work for asynchronous, callback-based APIs.
It’s gross that we have two totally different ways to handle errors based on whether the following line needs to use the output from the previous line, and whether it’s called immediately, or after an async calculation. And Swift’s try/catch semantics do nothing to help reduce the error handling boilerplate needed inside callbacks.
And “throws” is probably best thought of as somewhat opaque sugar around an Either type.
(Int) -> String is a subtype of
(Int) throws -> String, which is
pretty awesome and a little subtle, but we’ll get to that in another post.
So that tells us that a non-throwing closure can be used anywhere a throwing closure is requested, just like a Cat can be used anywhere an Animal is requested. No conversions necessary. It’s just types.
Luckily, Swift is much smarter than that. It’s nice that you can overload based
on throwing, but in many cases we have a better tool. We can mark the method
rethrows rather than
func map<T>(@noescape transform: (Generator.Element) throws -> T) rethrows -> [T]
So what promise does
rethrows make? It promises that the only way it will
throw is if a closure it is passed throws. So if it’s passed a closure that
can’t throw, the compiler knows that the function can’t throw either.
Internally the rethrowing function uses the
try keyword as usual, but does not require the
catch elements. It is only when the function is called that the do-try-catch syntax is employed.
If you’re working with asynchronous closures, you’ll need to supply ones that do not use throwing signatures. Convert your closures to non-throwing versions by providing exhaustive catch clauses.
Update (2015-06-22): jemmons:
It’s telling that exceptions have arrived in the language alongside multi-payload enums. This makes it trivial to create
Either types without the awkward, inefficient boxing of values previously required. And it would seem exceptions take advantage of this.
throws is just syntactic sugar.
Update (2015-06-25): Juan Pablo Claude:
Swift 2.0 does a great job of coalescing the history of error handling in Cocoa and Cocoa Touch into a modern idiom that will feel familiar to many programmers. Unifying behavior leaves the Swift language and the frameworks it inherits in a good position to evolve.
Thursday, June 18, 2015 [Tweets]
Almost four years ago, Dev reported a bug with Core Data’s
NSOrderedSet generated accessors (via Ling Wang).
DaGaMs, in 2013:
I just brought this up with an Apple engineer during one of the CoreData Lab sessions at WWDC. They acknowledge the issue and that it’s a genuine bug, and from what I’ve seen it has the “critical” status, but of course there’s no promise as to when they’ll fix it. I don’t think it’ll be fixed in iOS6/Mountain Lion. I think it’d be good to duplicate this radar further. Currently it has about 25 dup’s, the more the better!
It seems like an important and straightforward bug to fix, but it’s still present in iOS 9.
Another bug, reported by Michael Gorbach (tweet):
We have found a reproducible CD deadlock that can occur when using a fetched results controller with a “complex” (i.e. either multi-level or “synthesized” (not in the database) sectionNameKeyPath). This occurs specifically with a stack that has a top-level background (private queue) writing context, where the main thread context is a child of this context.
Changes to CD (object creations and updates) as well as fetch requests, are taking place sequentially on background “import” contexts (private queue contexts). These contexts are also children of the top-level private queue writing context. If, while these CD changes and fetch requests are taking place in the background, the main thread Fetched Results Controller is asked to perform it’s initial fetch, a deadlock results.
Now you can manage tasks in Editorial like a boss. Editorial provides built-in support for the TaskPaper format with handling of projects, tag highlighting and completing tasks for files saved with the .taskpaper extension. The iPhone version now has feature parity of the task management features, including check boxes and drag handles to move tasks up and down a list.
First, jump into the Editorial preferences and make a few tweaks. Editorial will highlight lines with user configured tags.
This is an Editorial script that I use many times a day. I’ve added it as an action on almost all of my Taskpaper macros. The script processes every line of the Taskpaper looking for @due tags that contain dates with the format YYYY-MM-DD and evaluating those against today’s date. If the date is equal to or less than today, it changes the tag to @today.
Document Templates in Editorial 1.2 are really just macros that execute before you open a document. Out of the box, there are some simple templates that create new documents with different file extensions. But this is the least a template can do.
Editorial (App Store) is my favorite iOS text editor. There’s also a new feature for highlighting all occurrences of a word at once.
Update (2015-06-22): Gabe Weatherhead:
If you use it as much as I do, you may find these additional macros useful. Editorial is a means for working with text and often it can seem like a heavy IDE that requires a huge time investment. Most of the macros below are simple or use basic “actions” in a logical way.
Only two apps are visible, neither of which are a) Twitter clients or b) made by Twitter or c) even remotely related to Twitter.
The most important store front on the most important mobile device is seven years old and still has the worst search experience I’ve ever used.
Previously: How Broken is Discovery on the App Store?
It is an area were we want to do better. We are working on new tools to enable content blocking at a fraction of the cost.
One new feature, we are developing allows describing content blocking rules in a structured format ahead-of-time, declaratively, rather than running extension-provided code at the moment a decision about blocking needs to be made. This model allows for WebKit to compile the ruleset into a format that’s very efficient to apply to loads and page content.
Dave Baggett (via John Carmack):
The PS1 had 2MB of RAM, and we had to do crazy things to get the game to fit. We had levels with over 10MB of data in them, and this had to be paged in and out dynamically, without any “hitches”—loading lags where the frame rate would drop below 30 Hz.
It mainly worked because Andy wrote an incredible paging system that would swap in and out 64K data pages as Crash traversed the level. This was a “full stack” tour de force, in that it ran the gamut from high-level memory management to opcode-level DMA coding. Andy even controlled the physical layout of bytes on the CD-ROM disk so that—even at 300KB/sec—the PS1 could load the data for each piece of a given level by the time Crash ended up there.
I wrote the packer tool that took the resources—sounds, art, lisp control code for critters, etc.—and packed them into 64K pages for Andy’s system.
Wednesday, June 17, 2015 [Tweets]
First, I want everybody to know about the ridiculous stunt Apple is trying to pull here. I’d have been perfectly happy if they had just sent me an e-mail saying they were going to include my feed, and if I didn’t like it I could e-mail to opt out. I’d even be happy if they didn’t even give the option to opt out! After all, having an RSS feed in the first place is an implict opt-in to that sort of thing. But trying to dictate terms on top of that while telling me that I automatically agree to them unless I opt out is unacceptable, even if the terms themselves are relatively benign. They should stop doing this, and telling people about what they’re doing is the only way I know that might help to make that happen.
My guess is that this was just clumsy communication on Apple’s part. As Ash later says:
I wager the intent was a courtesy notification, but unfortunately they wrote it as a crazy EULA-like magic contract. I don’t think they are actually claiming anything they don’t already get under the law, but the way they word it is awful.
So the issue is not what Apple is actually doing but rather that someone approved such tone-deaf language. It’s the opposite of the human side that Apple just presented at WWDC.
Darren Pauli (comments):
Six university researchers have revealed deadly zero-day flaws in Apple’s iOS and OS X, claiming it is possible to crack Apple’s password-storing keychain, break app sandboxes, and bypass its App Store security checks.
Attackers can steal passwords from installed apps, including the native email client, without being detected, by exploiting these bugs.
The team was able to upload malware to the Apple app store, passing the vetting process without triggering alerts. That malware, when installed on a victim’s device, raided the keychain to steal passwords for services including iCloud and the Mail app, and all those stored within Google Chrome.
Luyi Xing et al. (PDF, Google Drive) found four main vulnerabilities. On the Mac, controlling a target application’s keychain items:
One scenario for this exploit is that when the malware runs before the victim app creates a password (or rather a keychain item) in the keychain. What the attacker can do here is to use the attributes of the target app (the victim) to claim an item and also craft an ACL that includes the target as a trusted app. When the target uses the keychain to store password, it discovers the item with its attributes already there and treats the item as its own secure storage (illustrated by the Apple’s template code in Figure 2). Note that this is reasonable given that an app’s older version or other apps from the same developer may have already been installed on the system. Since the target is on the ACL of the item (which is controlled by the attacker), the OS allows all its operations to proceed. Therefore, at no point the target gets any indications from the keychain that it is just a guest user of the item, and the owner is untrusted. This confusion will cause the target to divulge its secrets to the attacker, whenever it updates the user’s credentials to the keychain.
We checked the most recent OS X 10.10.3 and beta version 10.10.4 and found that they attempted to address the iCloud issue using a 9-digit random number as
accountName. However, the
accountName attribute for other services, e.g. Gmail, are still the user’s email address. Most importantly, such protection, based upon a secret attribute name, does not work when the attacker reads the attribute names of an existing item
and then deletes it to create a clone under its control, a new problem we discovered after the first keychain vulnerability report and are helping Apple fix it.
Using a helper with the target’s bundle identifier to access the contents of its container:
Interestingly, we found in our research that the MAC Store fails to verify whether a sub-target’s BID is in conflict with those belonging to other apps or their sub-targets, except for the Apple reserved BID (those starting with com.apple). This allows one to publish an attack app whose helpers or XPC Services are using the BIDs of other apps, their helpers or XPC Services. Once the attack app is launched, whenever the OS finds out that the container directory bearing the sub-target’s BID (as its name) already exists, the sub-target is automatically added onto the directory’s ACL.
Intercepting communication from the 1Password browser extension to the 1Password helper application:
In our research, our sandboxed app created a local WebSocket server that took over the port 6263, before the 1Password app did, and was successfully connected to the password extension and downloaded the password whenever the user logged into her web account. We reported our findings to the 1Password security team, which acknowledged the gravity of this problem. This attack succeeded on OS X 10.10 (latest version when we reported the problem), against Chrome, Firefox and Safari. Our attack code passed the vetting process of the MAC Store.
And, on iOS, intercepting credentials by hijacking a URL scheme:
Scheme hijacking poses an especially serious threat to iOS, which heavily relies on URLs for interapp interactions (Section 4.2). As an example, we exploited this weakness and successfully obtained the victim’s Facebook token for Pinterest, the most famous personal media management app. […] Most importantly, once it got the secret to- ken from Facebook, the attacker forwarded it to the Pinterest app through “fb274266067164://”, which completely hid the attack from the user
Lead researcher Luyi Xing told The Register that he reported the security flaws to Apple in October 2014 and complied with the iPhone maker’s request to withhold publishing the information for six months, but has not heard back from the company since and is now exposing the zero-day vulnerabilities to the public. The flaws affect thousands of OS X apps and hundreds of iOS apps and can now be weaponized by attackers.
Apple’s review process for the App Store—both for iOS and OS X—is supposed to prevent malware from entering its system. If that bulwark fails, the company relies on sandboxing, which prevents apps from accessing data and files other than that managed by the app, except through very tightly defined channels.
In this case, both failed.
It’s not the first time researchers have found flaws in application sandboxes. The attack exploiting WebSocket weaknesses, for instance, can also succeed in Windows under certain conditions, the researchers said. Interestingly, they said application sandboxing in Google’s Android OS was much better at withstanding XARA threats.
In light of the vulnerabilities, users of all OSes should limit the apps they install to those that are truly needed and explicitly trusted.
The threat is that a malicious Mac app can pretend to be 1Password mini as far as the 1Password browser extension is concerned if it gets the timing right. In these cases, the malicious app can collect Login details sent from the 1Password browser extension to the fake 1Password mini. The researchers have demonstrated that it is possible to install a malicious app that might be able to put itself in a position to capture passwords sent from the browser to 1Password.
Note that their attack does not gain full access to your 1Password data but only to those passwords being sent from the browser to 1Password mini.
It is important that the threat only affects communication in one direction. If you always update your passwords directly in 1Password, rather than relying on the extension to send them to the helper, it shouldn’t affect you. [Update (2015-06-18): Make sure that you uncheck “Automatically ask to save new Logins”.] And it’s still safe to use the main feature of 1Password, sending the password to the browser extension.
Neither we nor Luyi Xing and his team have been able to figure out a completely reliable way to solve this problem. We thank them for their help and suggestions during these discussions. But, although there is no perfect solution, there are things that can be done to make such attacks more difficult.
The Register’s subheadline, “Keychains raided, sandboxes busted, passwords p0wned, but Apple silent for six months” made me think that all of my 1Password data was at risk. After all, with Touch ID the master password is stored in the iOS keychain. However, putting together the details above, it sounds like this should not be a concern because the keychain and container vulnerabilities only affect the Mac.
Update (2015-06-18): Jeff Johnson:
I don’t understand all the hubbub about the “Unauthorized Cross-App Resource Access” paper. How can you possibly expect your system to remain secure if you’re already running malware? The important thing is to prevent malware. If you fail, you’re screwed.
We already knew that Apple’s app review was a joke, so that’s nothing new. Malware can easily get through that. You can’t expect to install apps from random, unknown developers and remain safe.
The promise of the Mac App Store and sandboxing is that this is safe. There isn’t supposed to be malware in the store, and even if there is it shouldn’t be able to affect your other apps.
There are many ways to get sensitive information from any computer system, including phishing, spoofing, and social engineering attacks, but XARA is a serious group of exploits and they need to be fixed (or systems need to be put in place to secure against them).
Update (2015-06-19): Nick Arnott:
Ultimately, we’ll have to wait and see where Apple goes from here. Several of the above items seem like bonafide, exploitable security bugs to me; unfortunately, until Apple fixes them, your best bet is to stay cautious and monitor the software you install.
Update (2015-06-21): Brett Terpstra:
Most of the vulnerabilities reported are related to “legacy” systems that Apple built on top of the OpenBSD framework, such as the Keychain, url handlers, inter-app communication systems. These are all things that make OS X great to use, so we’re walking the line between security and convenience again. Most of what I do every day relies on these technologies.
I’m sure there will be increased scrutiny of all App Store apps using these systems for communication and credential storage. I’m hoping that we don’t just see the pod bay doors snap shut, but that we’ll see new, more secure means of handling the flexibility some of us love.
Earlier this week we implemented a server-side app security update that secures app data and blocks apps with sandbox configuration issues from the Mac App Store," an Apple spokesperson told iMore. “We have additional fixes in progress and are working with the researchers to investigate the claims in their paper.”
Friday, June 12, 2015 [Tweets]
David Owens II:
It took me a little while for me to really appreciate the design of
throws. At first, it was sheer disbelief that the Swift team created exceptions. Then it was mild irritation that a
Result<T, E> type wasn’t used.
We aren’t the only ones that think Result, or a type like it, is a solid solution for error handling in Swift, so it took me by surprise that the Swift team went in a seemingly different direction with Swift 2’s new error model. That is, until I started working with it in my own code and found that it did almost everything my Result-based handling does and did it in a cleaner manner.
Swift 2 provides error handling by the means of several new keywords: do, try, catch, throw, throws. To indicate that a function or method can provide an error, you mark it with throw. Errors cannot be thrown within functions or methods that lack this marking. Similarly, error-throwing functions or methods cannot be used without using the try keyword before them. All errors must either be caught (using do/catch), or passed upward (at which point the function or method must be marked as throws).
Multiple error-throwing functions can be called in sequence, but the first to throw an error aborts execution at that point. An error being thrown acts more like a return statement than the older-style Objective-C NSExceptions, and plays nice with ARC.
My initial reaction was that Swift 2’s error handling is a bit of a hack, a lot of keywords and compiler magic to not give us real exceptions. But Swift fixes some of the problems with exceptions in other languages. And it fixes the main thing that was wrong with the Objective-C
NSError model, which is that it was very verbose. Most importantly, it doesn’t turn ordinary code into a mess of types and closures, which is what I feared Apple was going to do.
I look at what it does to Larson’s code, and I’m impressed. And he hasn’t even showed what
defer can do. So, although it’s unusual, I think this is going to work out well in practice.
There’s still work to be done, though. Swift still can’t handle actual exceptions raised by Objective-C code. They’re treated as runtime errors that bring down your whole program. So some important Cocoa APIs—plus anything with assertions—is off-limits.
See also: the two Swift books and my WWDC 2015 Links post.
Update (2015-06-12): I am going to miss the automatic stack traces that I would get with either true exceptions or my Objective-C
NSError propagation macros.
Chris Lattner (contra Mark Gurman):
There were no public statements that Swift 2.0 would eliminate that requirement (just some rumor sites claiming that) and in fact Swift 2 will continue to require the standard library in your app.
We are interested in making Swift ABI stable going forward, but will need more time to settle things out. In particular, we want to make sure that we get to incorporate ideas and feedback from the open source community before locking things down.
This is really good news for Swift in the long term. However, it does make deployment less attractive in the short term. Gurman says that the libraries for an application take up 8 MB. I found that a Hello World command-line tool is 3.6 MB. Regardless, this gets multiplied by the number of binaries in your application: background helper app, XPC service, Spotlight importer, Quick Look plug-in, Automator action, command-line tool, etc.
Update (2015-06-15): It is not always the case that there will be duplicate copies of the Swift libraries for each binary. For example, a .appex bundle will automatically link to the libraries in its containing app. Xcode 6 does not seem to do this automatically for other bundle types, but in theory a future version could. Any binary such as a command-line tool that could be moved, relative to the main application, probably needs to embed its own copy of the libraries.
This, I believe, is an important distinction to make when assessing the iPad’s adoption of features that have been exclusive to desktop computers. The iPad’s improved capabilities in iOS 9 are options – deeply integrated with the operating system through gestures, but, ultimately, not the default way to interact with apps. Compare the new iPad multitasking to OS X: when you launch an app on the Mac for the first time, it defaults to window mode without taking up the entire screen; in iOS 9, iPad apps will launch in full-screen as usual and allow you to view a secondary app only when needed.
iOS 9 is going to be a watershed moment for iPad users. For many, the iPad is about to graduate from utility to computer. Apple is envisioning a future where users can do more with iPad apps without the inherent complexities of OS X – and they’re largely relying on developers to help build this future.
While Slide Over will be available on older iPad models, the more useful and versatile Split View will only be available on the latest iPad Air 2. Will that slow adoption among users stuck on older iPad models, or will it push people who want to do more on an iPad to buy a new one? How quickly will developers react and update their apps for multitasking? Is this going to revitalize the iPad productivity app market, which has been a bit stale and unimaginative in the past couple of years? Is it kind of obvious at this point that a larger iPad with more comfortable split view multitasking is coming?
For people who own (or are considering purchasing) an iPad, the forthcoming release of iOS 9 is the biggest most exciting event since the iPad was released in 2010.
With Split View (available only in the iPad Air 2 for now), Slide Over and Picture in Picture, you can finally interact with two apps simultaneously. With the new QuickType “trackpad simulator,” you can move the cursor around much like you do on a Mac, eliminating the need for the loupe tool. There’s now a system-wide shortcut toolbar. There’s even a Mac-like app switcher than you can call up with Command-Tab on a Bluetooth keyboard. I’ve tested all these out with the iOS 9 beta and can attest that they work pretty much as advertised.
Update (2015-06-19): Lukas Mathis:
This seems to add additional inconsistency to an already odd implementation of the split window feature.
This reminds me of 90s Internet mystery meat navigation, except that there’s not even any mystery meat, and you’re just randomly dragging around and tapping on things to trigger actions that might or might not be supported by the application you’re actually trying to use. You could argue that split view is a power user feature, and power users can just go watch a YouTube movie that explains how the feature works, but I’ve now watched this section of the keynote twice, forgotten how it works once already, and I’m completely sure that I will have forgotten how it works again by tomorrow.
This is exactly the kind of magical user interface that people have faulted Windows 8 for, except it’s even more confusing. In Windows 8, you only had to remember to swipe in from the screen edges. Once you did that, the UI was visible, and guided your actions. In iOS 9, it’s layers of hidden UI magic. The one advantage Apple has is that you don’t need to know any of it to use iOS, but still. I think we should expect better of Apple.