Archive for June 2015
Tuesday, June 30, 2015 [Tweets] [Favorites]
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.
Update (2015-07-05): Kevin Walzer:
I’ve done enough work on Windows and Linux to know that I can certainly develop for those platforms, but there’s a reason I stay with the Mac--even using a cross-platform toolkit. It is by far the best environment for developers. I absolutely love developing for the Mac, even in spite of Apple’s many restrictions, even as I move out of the Mac App Store for good.
If my work on the Mac isn’t very rewarding financially, it can at least be rewarding in terms of enjoyment.
Update (2015-07-12): Oluseyi Sonaiya:
This outcome was entirely predictable.
Put more bluntly, Apple is not your friend.
This is an unpopular opinion among Apple fans, users and developers alike, and I think it’s because of Love. The iOS indie space is filled with and shaped by former and current Mac indies, especially from the years when Apple was not the dominant platform vendor, as well as lifelong fans of the company and its products. These are people who love Apple, and I think it blinded them to the fact that Apple now works at cross-purposes with them.
Yes, Apple is just people, but Apple is also a corporation and corporations are rather ambivalent about people. Despite the sincerity of individuals at nearly any level of a large corporation, the aggregate force of shareholder interest, profit and competition will frequently drive a corporation to act against you. Dijkstra warned us not to anthropomorphize our programs. Neither should we anthropomorphize our platforms, or the corporations that control them.
I saw a report (and promptly forgot where) that about 12,000 new games come out each month. […] Right now, Apple features about 15. And they do want to mix it up so it is not all the same type: some action games, some puzzles, some driving ones, etc. So you don't have to be in the top 15 out of all 3,000 to get featured, its more like the top one or two out of the style of game you make, so say the top 2 out of 500.
People who buy Rego love it, and discover all sorts of interesting ways to use its versatility. One guy journals his travels. Another tracks her photo shoots. And yet another tracks drilling locations in Kuwait!
But if I divide our development time by the revenue we’ve made, it works out to an hourly rate of about 1/4 of minimum wage.
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. :(
Update (2015-07-06): John Gruber:
What irks the open web crowd isn’t that Safari is the new IE, but that Apple wields utter control over iOS—and most users are happy w/ that.
It’s not clear to me how the second part is any different from what the situation with IE was. At least Windows let you install Firefox (and later Chrome) if you didn’t want IE. You could even set them as the default browser.
Update (2015-07-07): Don Melton:
Folks keep asking me to comment on that article today. Let me be clear: Safari is not the new I.E. There is so much wrong with that piece.
What Lawson is mistaking for complacency is actually an evolution of perspective. Safari and WebKit won the battle for better web technology. Now they’re fighting the battle for better security, privacy, and performance (including energy efficiency).
None of this is new—the culture of zero regression has been ingrained into the WebKit and Safari teams since their founding—It’s simply moving from purely technical features to user-facing features.
I don’t find this very convincing because it assumes that Web technology is static. In fact, the Web is evolving apart from Safari, and I have lately seen more sites that don’t work with it. And the culture of “zero regression” is exaggerated because the Safari team made huge performance and stability regressions when they sandboxed the rendering engine. Apple’s priorities for its browser have changed, just as Microsoft’s did.
I thoroughly enjoyed the resulting debate, though, and yes, there are valid arguments on both sides. So I’d like to pick up where I left off, and respond to my detractors while doubling-down on my claim that Safari is acting as an anchor in the web community. I’ll also end on a hopeful note, with some suggestions for reconciliation with Apple.
That being said, my point was to compare Safari to IE in terms of 1) not keeping up with new standards, 2) maintaining a culture of relative secrecy, and 3) playing a monopolistic role, by not allowing other rendering engines on iOS. Those accusations are pretty undeniable.
Personally what I want out of this whole debate is for Apple to realize that the web is starting to move on without them, and that their weird isolationism and glacial release cycle are not going to win them any favors in this new, dynamic web community.
Update (2015-07-11): See the discussion on Accidental Tech Podcast, although it focuses more on whether Apple’s Safari decisions make sense, rather than on whether the analogy with IE is correct.
Kenneth Auchenberg (comments):
The problem isn’t Safari. It’s a somewhat modern browser that in the eyes of some might lack some important features, but overall is still pretty good and modern.
The real problem is Apple’s lack of browser-choice in iOS, and that’s a problem for several reasons[…]
Update (2015-07-30): On the Debug podcast, Don Melton responds to Nolan Lawson. His argument essentially is that Safari is not in stasis like IE was, but that Apple has its own very different development priorities. The corporate secrecy policies make it seem like the Safari team is not participating, but there are channels such as mailing lists and Twitter where you can interact with them.
Update (2015-09-25): John Gruber:
The difference is that IE 6, at its peak, wasn’t just so popular that it allowed Microsoft to unduly influence the direction of the web — IE 6 was so popular that it allowed Microsoft to define the web. It was as though IE 6 was the web. When banking sites required ActiveX plugins, they were making websites that only worked in Internet Explorer, only on Windows. In the eyes of many web developers and publishers, it was the one and only browser that mattered.
There is no official “Web Standards Security Council”, but web browsing market share creates a de facto one. Apple (or Google, or Microsoft, or Mozilla) can’t single-handedly veto a new API from becoming an official W3C standard, but if any one of them decides not to implement it, it can’t be relied upon by web developers.
Thursday, June 25, 2015 [Tweets] [Favorites]
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.
Update (2015-07-09): Daniel Jalkut:
FYI the provision about MapKit outside the Mac App Store is no longer in the beta 3 release notes :-\
At least in practice I have confirmed the relaxation is still working in beta 3. Hopefully just an oversight.
Fantastical uses @Mapbox, not Google, FWIW.
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.
Update (2015-07-07): Kyle Orland:
Reports and public statements from Apple suggest the company is working to reinstate games that use the flag in an “educational or historical” context.
Despite that statement, yesterday saw the App Store removal of numerous games that use the Confederate flag merely to represent the Southern side in historical war simulations.
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.
Jacob Krall (comments):
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.
Update (2015-07-12): tptacek:
Quick rant: if this had been a Lisp project, and they’d accomplished this stuff by writing macros, we’d be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy.
Let me start by saying that Wasabi as a strategic move was brilliant. If David disagrees there, I’m a bit surprised: FogBugz represented an awful lot of battle-tested low-bug code, and finding a way to preserve it, instead of rewriting it, made one hell of a lot of sense. I’m with you that the general thoughts in this forum that we’d have to be insane to write a compiler are misguided. Wasabi let us cleanly move from VScript and ASP 3 to .NET without doing a full rewrite, and I’d be proud to work at a place that would make the same decision in the same context with full hindsight today.
That said, I think Wasabi made two technical decisions that I disagreed with at the time and still disagree in with in retrospect. First, Wasabi was designed to be cross-platform, but targeted .NET prior to Microsoft open-sourcing everything and Mono actually being a sane server target. At the time, I thought Wasabi should’ve targeted the JVM, and I still think in retrospect that would’ve been a much better business decision. I really prefer .NET over Java in general, but I know that it caused us an unbelievable amount of pain back in the day on Unix systems, and I think we could’ve avoided most of that by targeting the JVM instead. Instead, a significant portion of "Wasabi" work was actually spent maintaining our own fork of Mono that was customized to run FogBugz.
Second, Wasabi worked by compiling to C# as an intermediary language. There was a actually an attempt to go straight to IL early on, but it was rejected by most of the team as being a more dangerous option, in the sense that maybe three people on staff spoke IL, whereas pretty much everyone could read C#. I also think this was a mistake: the C# code was not human-readable, made debugging more complicated (VS.NET had something similar to source maps at the time, so it wasn’t impossible, but it was very indirect and quirky for reasons I can get into if people are curious), and that decision meant that Wasabi had all of the limitations both of its own compiler, and of Microsoft’s C# compiler. IMHO, these limitations are a big part of why the ultimate move away from Wasabi was even necessary in the first place, since they increased both the maintenance and developer burden.
So from my own perspective, I think that Wasabi was a mistake in that, if we were going to go to C#, we should’ve just got the translation good enough to really go to C# and then ditch Wasabi; and if we weren’t, we should’ve actually owned what we were doing and written a genuine direct-to-IL compiler so we’d have more control over the experience, instead of going through C#. But I still really do genuinely believe that our going to Wasabi was a brilliant strategic decision, and I think Fog Creek would have suffered immeasurably had we not done it.
Update (2015-07-16): Jacob Krall (comments):
I am also releasing Wasabi’s new code generator as open source software. I believe this is the first real-world transpiler targeting C# with Roslyn to be open sourced. It is my hope that this article and associated source code will serve as a rough guidepost for anyone who wants to write a .NET code generator using Roslyn.
We anticipated that CodeDOM would provide some level of static typing to our code generation process, as our previous generators always included a period of fixing obvious typographical errors (a missing semicolon here, an extra open-bracket there). CodeDOM also exposed a handy method for compiling directly to C#. However, we were slightly disappointed when we discovered that CodeDOM simply writes to disk and shells out to csc.exe. Another irritation was that word “common” I included in my description of CodeDOM: it is a lowest-common-denominator tool. Basically, the output was intended for a compiler, not human consumption.
CodeDOM’s representation is a mutable graph, so I would often pass node references as parameters and mutate them in other methods. Roslyn represents source code as an immutable graph of nodes, so the correct way to generate a given node is from the bottom up. However, because I was trying to modify a copy of the CodeDOM generator into shape, I had to change the calling convention of some of the methods which depended on mutation. There are many convenience methods in Roslyn to allow you to create a mutated copy of your node, but it wasn’t always clear where the result should be stored.
One complaint I have about Roslyn is with the SyntaxKind type – for performance reasons, it is implemented as a gigantic enum. However, this means it is not type safe – you can pass any SyntaxKind to any method that takes one, even where doing so will cause an inevitable crash. I ended up having to fix dozens of cases where I passed the wrong SyntaxKind (for example, passing a QuestionToken where I meant to pass a ConditionalExpression), and Roslyn would throw an exception.
Although slightly off-topic, I find the mentioned idea of “syntax trivia” very compelling. This should not only be part of code parsers, but of any parsers.
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] [Favorites]
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] [Favorites]
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 (comments):
Apple’s impulsive response to Swift stands in stark contrast to their treatment of indie app developers, who have been lobbying Apple for almost seven years, requesting Apple reform policies in the App Store to no effect. In particular, Cue’s use of the word “indie” can only be described as a callous slap in the face given the circumstances that indie developers have been facing.
Developer reactions have been mixed: Daniel Jalkut of MarsEdit exclaimed, “Damn, I wish Taylor Swift were also a Mac App Store developer.” Cabel Sasser rightly pointed out that complaints by developers have and will likely continue to be ignored: “As if ANY of us nerds have 1/100000th the public perception pull of a Taylor Swift.”
Developer David Barnard pointed out the utter inconsistency here between music and app development: “Apple is subsidizing a 90 day free trial for Music, but there’s still a rule in the App Review Guidelines prohibiting timed trials for apps.” In other words, musicians complain that they will not get paid—Apple immediately subsidizes them. Developers on the other hand do not even have the option of using that marketing strategy.
Update (2015-07-12): Ben Sisario (via John Gruber):
For each song that is streamed free, Apple will pay 0.2 cent for the use of recordings, a rate that music executives said was roughly comparable to the free tiers from services like Spotify. This rate does not include a smaller payment for songwriting rights that goes to music publishers; Apple is still negotiating with many publishers over those terms, several publishing companies confirmed on Wednesday.
Update (2015-07-14): Michal Lev-Ram (via Konra):
Scott Borchetta—who discovered and signed Swift when she was only 14 years old—told the audience that the conversation actually started between him and Apple in the days preceding Swift’s letter.
“She literally texted me and said, ‘Don’t be mad,’ with the link,” Borchetta said. “She was in Europe. I responded and said, ‘You don’t have any idea how good your timing is right now.'”
After Swift’s letter made huge waves, Borchetta’s conversations with Apple quickly turned to his (and, presumably, artists’) favor.
Update (2015-08-21): Mitchel Broussard:
In a new interview with Evening Standard, Apple Music executive and Beats co-founder Jimmy Iovine sat down to talk about everything from the launch of Apple Music to the company’s dramatic reversal of its free trial royalties policy following Taylor Swift’s public dismissal of the service in an open letter.
In an interview for the September cover story of Vanity Fair, Taylor Swift reveals her thoughts and reasoning behind the letter she wrote to Apple concerning the lack of monetary support for artists during Apple Music's three-month free trial period. The singer notes that she wrote the letter in the early morning hours after a few of her fellow artists sent pictures of their Apple Music contracts.
“Apple treated me like I was a voice of a creative community that they actually cared about,” Swift told Vanity Fair. The magazine calls Swift an “Apple Music crusader” with the “willingness to take on tech giants.”
Sunday, June 21, 2015 [Tweets] [Favorites]
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] [Favorites]
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.
Update (2015-07-12): Keith Harrison:
The default for how numbers are displayed is changing from monospaced to proportional[…]
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] [Favorites]
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] [Favorites]
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] [Favorites]
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.
Update (2015-07-27): Sam Marshall:
There is a build setting named
EMBEDDED_CONTENT_CONTAINS_SWIFT which stores a boolean value. There is an Apple Q&A document that describes how to use this, however there are some assumptions made as to how this flag is to be used.
When enabling the
EMBEDDED_CONTENT_CONTAINS_SWIFT flag on a target, a new step is added to the build process. This step runs the target’s build product through a tool called
swift-stdlib-tool, which parses the binary header to get the list of linked dependencies (frameworks/libraries). It will then check the paths of these linked dependencies to see if any of them contain references to the Swift runtime 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.
Amazingly, people were finding Comfy Read solely via the App Store search without me having to do anything. I cannot overstate its importance.
With Apple making analytics available on iTunes Connect, I was amazed to see that Comfy Read was having conversion rates of anywhere between 6 and 9%. Pretty amazing for an up-front paid app, I thought.
Will v2.0, the freemium app that a lot more users are downloading beat v1.0, the older version, financially? Not by a long shot.
Freemium is hard. Its effectiveness depends on where you can put that purchase barrier in your app. Many app types simply don’t have a good place for it.
I spent months debating which features should be behind Overcast’s in-app purchase. If I limited the number of subscribed podcasts for free users, I’d be discouraging people from trying new podcasts. If I put Smart Speed, Voice Boost, and my smart playlists completely behind the paywall, most users would never experience my best features and wouldn’t think my app was very good. But if I kept the paywall too easy to avoid, like showing ads with a purchase to remove them, it wouldn’t sell well. (No-ads upgrades never sell well, by the way.) And whatever features I limited would be free in many competing apps, including the one Apple includes on every iPhone for free.
Hermann Zapf, whose calling in life — “to create beautiful letters,” as one of his students put it — found expression in lush, steady-handed calligraphy and in subtly inventive typefaces that have brought words to readers on paper, on signposts, on monuments and on computer screens for more than half a century, died on Thursday at his home in Darmstadt, Germany. He was 96.
Working with these elements, Mr. Zapf evoked beauty as well as clarity, cleverness without hubris, invention without distraction. A master calligrapher who could reproduce a typeface by hand, he brought an admiration of the art of the pen to the art of the font. And conscious of history, he felt that type should both acknowledge tradition and reflect modernity.
Anna Quito (via John Gruber):
In his long and prolific career, Zapf worked on many fonts, but his personal favorite was the humanist sans serif typeface Optima, the lettering chosen for the Vietnam Veterans Memorial wall in Washington, DC.
Zapf was among the pioneers of computerized typography, experimenting with computer-aided typesetting from the 1960s. He led a seminal design program at the Rochester Institute of Technology where collaborated with computer scientists and became acquainted with IBM and Xerox. Zapf invented a typesetting program called Hz-program, which later informed the design of the desktop publishing software Adobe InDesign.
Adam Twardoch (via Hacker News):
But his contributions went way beyond that — Hermann Zapf served as typographic advisor to both Dr. Peter Karow (URW) and Professor Donald Knuth (TeX), the pioneers of computerized typography whose legacy we all benefit from today. Hermann had as much mastery in writing and drawing letters as he had in arranging them. The typographic arrangements that he devised are full of joy, beauty, balance and harmony — and deserve to be studied meticulously.
Palatino, Optima, and Melior were heavily used, I would say overused, in the late 1970s and early 1980s. A friend who went to Rochester Institute of Technology when Zapf was there (as a visiting professor, I think), said that in a lecture Zapf said that he had never intended Palatino to be used for body text, producing some gasps from the audience.
A couple of weeks ago, not long before my new book was published, Time Machine displayed the following helpful error message on my Mac: “Time Machine couldn’t complete the backup to ‘Backup Drive’. Unable to compete backup. An error occurred while creating the backup folder.”
When my backups become suddenly inaccessible for unknown reasons and I’m offered no solution but starting over, that sort of diminishes my faith in the software.
Then yesterday, Morgen’s laptop, which backs up to a completely different destination (a Time Capsule), displayed yet another error message: “Time Machine completed a verification of your backups on ‘Zora’. To improve reliability, Time Machine must create a new backup for you. Click Start New Backup to create a new backup. This will remove your existing backup history. This could take several hours. Click Back Up Later to be reminded tomorrow. Time Machine won’t perform backups during this time.”
I’ve encountered both of these errors, the first one with probably 10 different backup destinations, so I don’t think it can be blamed on hardware.
Thursday, June 11, 2015 [Tweets] [Favorites]
The Omni Group:
Push-triggered sync is a new feature in OmniFocus that uses push notifications to keep all your devices up to date. When OmniFocus receives a push notification, it can silently pull down changes from Omni Sync Server or your own private server, so you’re ready to go the next time you open OmniFocus. This all happens in the background without OmniFocus needing to be launched manually.
After OmniFocus finishes a sync, it asks the Device Registration Server to notify all the other devices associated with its Group ID. The server looks up all the Device Tokens in the group and sends them to Apple, and in turn Apple uses those tokens to issue a push notification to each of your devices. When one of your other devices receives a notification from Apple, it triggers a background sync in OmniFocus that pulls down the changes made on the first device.
To avoid syncing too frequently, OmniFocus includes the Tail Transaction ID in each push request. This randomly generated string identifies the last change made to the server database, so that if your iPhone already knows about the last change your iPad made, for example, the iPhone can prevent a sync and save on cellular data and battery. Transaction IDs include no information about what change was made.
Update (2015-09-23): Tim Ekl:
This way, parsing a configuration file can return one
ConnConfig struct for
each bundle ID that we’ll use to connect. The provider’s connection code can
then iterate over these structs, establishing multiple connections along the
Update (2015-10-14): Tim Ekl:
With this implementation, constructing an instance of this logging pipeline component is as simple as calling a function. It needs an existing channel as input, but gives back a new output channel; this means that we can easily chain multiple different components by passing the output channel from one function to the input of another.
For the push provider’s use, we can do a bunch of different things in each of these components – and logging is only the simplest! The provider itself is structured as a pipeline with nearly a dozen components from start to end[…]
Next up, we needed a way to hang on to notification information: what clients were registered with the provider, how they’re grouped, and some statistics tracking. We also needed to integrate with Omni Sync Server for a staged rollout of push: during testing, we enabled push only for some sync servers, in order to measure the kind of extra load that push would levy on our sync system. (Thankfully, this period was very brief, and push is enabled for every customer now.)
The Web portion of the provider was fairly straightforward. Rather than try to wrap Web access in Apache or nginx, or write a separate Web interface that called a push API, we used Go’s built-in HTTP and HTML templating support to handle all incoming HTTP requests and expose a simple but serviceable administrative interface.
The proof-of-concept attack exploits a flaw in Mail.app, the default iOS e-mail program. Since the release of version 8.3 in early April, the app has failed to properly strip out potentially dangerous HTML code from incoming e-mail messages. The proof-of-concept exploit capitalizes on this failure by downloading a form from a remote server that looks identical to the legitimate iCloud log-in prompt. It can be displayed each time the booby-trapped message is viewed.
Mitchel Broussard (comments):
Soucek says that Apple did not respond to his discovery of the bug when he stumbled across it back in January.
Soucek kept the details of the bug only between himself and Apple, letting the company have time to possibly fix the attack and inform him of its progress. Given the company’s remaining quietness on the subject, he decided to publish the proof of concept - called the Mail.app inject kit - on GitHub in hopes of spreading its awareness.
As part of its iOS 9 announcement on Monday, Apple revealed that all newer iDevices equipped with TouchID and running the newer version of the operating system will be required to upgrade from a four-digit to a six-digit passcode. Passcodes remain optional, and users can create a more complex alphanumeric password, but six digits will be the minimum. After 10 failed attempts to type in the code, the device will erase itself.
The issue up until now has been that web view hasn’t been allowed to store cookies for security reasons, so logins can’t persist. The solution that Safari view controller brings to the table is to essentially pull the information from Safari.
You can use
SFSafariViewController to display web content within your app. The Safari View Controller shares cookies and other website data with Safari, and has many of Safari’s features, like Safari AutoFill and Safari Reader. Unlike Safari itself, the Safari View Controller UI is tailored for displaying a single page, featuring a Done button that’ll take users right back where they were in your app.
Consider replacing your
UIWebView-based browsers with
SFSafariViewController if your app displays web content but does not customize that content.
Keyboard changes - The shift function has been altered once again, making it easier to determine when it’s activated and when caps lock is turned on. With shift pressed, all letters on the keyboard are now shown in upper case. With shift off, letters on the keyboard are lower case. On iPad, there are new edit controls, and the keyboard now uses the new San Francisco font.
In iOS 9, the left side of the QuickType bar will feature buttons for cut, copy, and paste; the right side will offer formatting options and a universal Attachments icon to quickly pick and share files. Apple calls this the Shortcut Bar, and developers will be able to enhance it with custom shortcuts for their apps.
Text selection has also been a major pain point in older versions of iOS, and Apple wants to tackle this aspect with a two-finger swipe that turns an iPhone and iPad into a trackpad for on-screen text. Simply place two fingers anywhere on screen (including over the keyboard) to start moving the cursor anywhere; tap & hold with two fingers to start a selection. In the demo on stage, Federighi showed how trackpad mode will enable small adjustments to cursor position across characters as well as bigger jumps across lines and paragraphs within a fraction of a second with a good mix of speed and precision.
Surprisingly, Apple also announced major changes for users of external keyboards. With iOS 9, iPad keyboards will be capable of opening the new Search page and an OS X-like app switcher similar to the CMD+Tab command found on desktop computers; in any app that implements the feature, you’ll be able to press and hold keys like Command, Option, and Control to view a popup of supported shortcuts.
Also, the traditional pop-up character preview iOS has always displayed when a key is pressed is not present in iOS 9, with its replacement being a darkened key which is largely hidden by one’s finger when typing. This is possibly a security enhancement by Apple, as technology exists for logging key presses via video analysis of the pop-ups above pressed keys from camera footage of someone typing on their device.
Additionally, a new method of moving the on-screen cursor and selecting text has been added in iOS 9 that utilizes a two-finger swipe anywhere on the screen, including over the keyboard, to quickly adjust cursor position or highlighted text. This feature works on both iPhone and iPad, and brings the hugely popular jailbreak tweak SwipeSelection’s functionality to iOS 9 in a way more optimized on iPad.
This sounds great.
Update (2015-06-17): John Gruber:
Trying iOS 9. With new keyboard, quickly getting used to “Character Preview” being off. Can’t get used to case-shifting on alphabet keys.
It sounds like all the keys switching case at once is distracting. There’s a way to turn that off, but then you run into the old Shift key confusion.
Update (2015-06-18): Peter N Lewis:
IMHO it’d be relatively easy to avoid the shift confusion by coloring it blue when it is pressed. Flipping Black/White wont work.
Update (2015-08-17): The swipe selection feature has unfortunately been disabled on the iPhone.
One change coming to iOS 9 – currently in beta – is the appearance of lowercase keys on the keyboard when the Shift key is not engaged. Many people like this, but I find it confusing.
However, you can turn this off, and display only uppercase keys, regardless of whether you’ve tapped the Shift key.
Tuesday, June 9, 2015 [Tweets] [Favorites]
- Download Xcode 7 Beta
- What’s New in Xcode (PDF, comments)
- Apple Developer Forums (a new set of forums that are viewable without logging in)
- WWDC 2015 Sample Code (intriguing CompressionSample doesn’t have any code, although there is a video)
- Testing with Xcode (PDF)
- Apple Developer Program (new combined membership)
- iCloud for Developers
- Apple News Publisher
- wwdc-downloader (bulk videos and PDFs downloader, via Daniel Jalkut)
- The Talk Show: Live From WWDC 2015, With Special Guest Phil Schiller (video, transcript), Live with Phil
- Apple Beta Software Program
- WWDC 2015 keynote: The fine print
- Jake Marsh on HomeKit, ReplayKit, and GameplayKit
- Videos: UI Testing in Xcode (notes), Continuous Integration and Code Coverage In Xcode Notes, Advanced NSOperations
- What’s New in Safari (PDF)
- WWDC notes by rtrouton
- David Owens II on Xcode UI Testing
- The interesting things from WWDC, iOS 9, Swift 2
- List of all WWDC 2015 Session Videos
- ASCIIwwdc (“Searchable full-text transcripts of WWDC sessions”)
- A Comprehensive list of New Stuff from #WWDC 2015 (via Natasha Murashev)
Friday, June 5, 2015 [Tweets] [Favorites]
Can’t happen soon enough, in my opinion. Yes, most people don’t want to pay $600-$700 for a brand new smartphone when they could be paying $200-$300—remember the original iPhone?—but the true costs have always been hidden. Your subsidy is built into your phone plan, but even after you’ve finished the usual two-year contract, at which point your phone should be paid off, your bill doesn’t go down. Madness.
I think this is one of the biggest potential threats to Apple’s iPhone sales. With subsidies, if you don’t upgrade your phone every two years you’re leaving money on the table. And it’s only $200 or so to get a new phone. But how many people would upgrade every two years if they actually had to pay the full price? And with hardware improvements that are more incremental than in the early years?
When the QuickType bar is enabled, the autocorrect suggestion will appear in the middle cell of the bar instead of as a floating balloon above the word, as it has done since the very first version of iOS. I find this far too subtle. Even more subtle is the way you ignore the autocorrect suggestion: since the bubble doesn’t exist for you to tap on to ignore it, you tap on the leftmost cell of the QuickType bar with your verbatim spelling. And that feels really weird to me.
This behaviour is something I never got used to, so I turned off the predictive keyboard days after publishing my review in September. This brings the keyboard back to a more iOS 7-like state, with classic autocorrect bubbles. But I still think something’s going on under the hood with the autocorrect engine.
I have tried pretty much all of the popular third-party keyboards for iOS — Fleksy, Swype, SwiftKey, Minuum, and so forth — running them for days to weeks at a time. And the keyboard that has stuck with me most has been — [dramatic pause] — the default one, for a singular reason: it’s the only one that feels fast.
Sure, pretty much all of the third-party keyboards you can find have a way better shift key than the default, and plenty are more capable. But I don’t type one-handed frequently enough to get a use out of a gestural keyboard like Swype; most of the time, I find these gestures distracting. Third-party keyboards also don’t have access to the system’s autocorrect dictionary, which means that developers need to build in their own autocorrect logic and users need to train the new keyboard. I didn’t think this would be as frustrating as it turned out to be.
Read the whole post, as he covers pretty much the whole OS, not just the keyboard.
Update (2015-06-11): Nick Heer:
While I like that the current implementation of multitasking keeps my phone fast and I don’t have to manually manage memory — not that you really have to do that on any platform — my experiences with Readdle’s Spark makes me wish that apps could spawn daemon processes. I’d like some way for a third-party app to declare that it is always running in the background with a small, memory-limited, higher-priority process.
I love the web browsing experience on my iPad, but if I’m doing two things at once — for example, replying to texts or an email — I almost have to have my phone beside me for it to be a less clunky experience. Switching between apps one at a time feels slow, and they usually need to relaunch because the iPad has never had enough memory.
Pipes creation will not be supported as of Aug. 30 this year. Pipes infrastructure will run until Sept. 30, 2015 in read-only mode to help developers migrate their data. Please visit http://pipes.yahoo.com/pipes for additional details.
Yahoo Pipes Blog (comments):
You can download your Pipe definition by specifying your Pipe-ID (_id) and the output format (_out=json) to the following end-point: http://pipes.yahoo.com/pipes/pipe.info
Before the creation of YQL, there was another product, called Yahoo! Pipes. This product provided much of the conceptual framework that became essential to come up with YQL. It was also very important because the real-world experience with users ended up exposing the need for a more advanced approach to the “Unix pipes for the web” initiative.
Update (2015-06-11): Rui Carmo:
In case you’re looking for a partial replacement, pipe2py works for a couple of my simple pipes.
I wondered what will happen to the people who follow feeds produced by Yahoo Pipes? Yahoo doesn’t say they’ll provide free redirection, but it would be good for the web if they did. However, even if they did provide redirection, where would people redirect to? Because Yahoo was a big company people trusted and their service was free, little if any competition developed for Yahoo Pipes. Either way, it’s a clear example of why it’s not good to depend on free commercial services to form critical parts of your content infrastructure.
Thursday, June 4, 2015 [Tweets] [Favorites]
Objective Development (App Store):
We just released our brand-new OS X app called Micro Snitch. It’s an unobtrusive little app that sits in your menu bar and notifies you whenever any app uses your Mac’s microphone or camera.
(Get it? It snitches on apps that use your microphone!)
In addition to showing this information in the menu bar, Micro Snitch also has a nice overlay that automatically appears in the center of the screen to get your attention whenever the microphone or camera starts being used. It then moves off to a corner to get out of your way.
It’s from the developers of the excellent Little Snitch, but unlike Little Snitch it’s just a regular app, no kernel extension required.
The situation worsened again, we received literally dozens of emails each week from angry users complaining
about some bundled software and toolbars that were added to the installer. Sourceforge did not (yet)
modify our installer in any way, instead our users were clicking on some of these misleading ads. I remember
counting more than seven “download” button on our SF.net page!
We couldn’t continue to operate this way so in April 2013 I started working on a new way to distribute VLC. We rented few servers, contacted some mirrors and everything was ready a couple of weeks later. We were finally able to pull the plug from the Sourceforge website.
Fast forward, end of May 2015 we heard about the Gimp binaries being bundled with the SourceForge installer and their
admin access taken over by some sf-editor1. We were quite surprised to
discover that the same happened to VLC, the project has been taken over without notice, removing all access to it but luckily
the binaries weren’t touched. Maybe because we’re now signing all of them for the Windows platform. And we’re now trying to
get our access restored
to avoid any further damage.
Reflection in Swift is a limited affair, providing read-only access to a subset of type metadata. While far from the rich array of run-time hackery familiar to seasoned Objective-C developers, Swift’s tools enable the immediate feedback and sense of exploration offered by Xcode Playgrounds.
The entry point for reflection is the
reflect function, which can take an instance of any type as its single parameter and returns a
MirrorType is something of an oddity for the Swift standard library: a protocol used as a type. Other than the ubiquitous
AnyObject, to date no other protocol is used this way. The particular
MirrorType-conforming instance that you receive depends on the type passed to
reflect—Swift’s internals define mirrors for types such as
Range, along with more generic mirrors for structs, classes, tuples, and metatypes.
MirrorType provides the nascent reflection API that Swift offers, wrapping a value along with its type information, information about its children, and different representations of the instance.
Lastly, we must link
WWDCSession to its custom mirror by adding conformance to the
Reflectable protocol. Conformance only requires a single new method,
getMirror(), which returns a
MirrorType—in this case, our shiny new
Update (2015-12-20): Benedikt Terhechte:
So, as you can see, using reflection slows the whole process of creating
NSManagedObjects down by about 3.5x. This is fine when you’re using this for a limited amount of items, or when you don’t have to care about speed. However, when you need to reflect over a huge amount of
structs, this will probably kill your app’s performance.
Trying to use Swift in any professional capacity is a joke. A very cruel joke. The “tooling” is terrible: compilation speed has been abysmal, and SourceKit spent the better part of the year as a punchline.
There’s so much new stuff to learn about. But it’s not the good kind of learning, where you expand your mind and discover new ways of thinking and working. It’s rote memorization of the six new inscrutable ways to make readonly properties. Learning that stuff won’t make you a better programmer or thinker, it’ll make you better at working around Swift.
Don’t get me wrong: that doesn’t mean I don’t think I can write great Swift ever, or that it’s not worth learning. It’s just not worth shipping code in right now. I love reading the blog posts, with people exploring and researching and trying to understand all the new things we can make.
Wednesday, June 3, 2015 [Tweets] [Favorites]
Yesterday evening, Apple CEO Tim Cook was honored for ‘corporate leadership’ during EPIC’s Champions of Freedom event in Washington. Cook spoke remotely to the assembled audience on guarding customer privacy, ensuring security and protecting their right to encryption.
“Like many of you, we at Apple reject the idea that our customers should have to make tradeoffs between privacy and security,” Cook opened. “We can, and we must provide both in equal measure. We believe that people have a fundamental right to privacy. The American people demand it, the constitution demands it, morality demands it.”
Cook said that Apple designs its products to “collect the minimum amount of data necessary to create great experiences.”
“You might like these so-called free services, but we don’t think they’re worth having your email or your search history or now even your family photos data-mined and sold off for God knows what advertising purpose.”
This statement, in my admittedly cynical opinion, is FUD — an effort to spread fear, uncertainty, and doubt. Cook and co. might truly believe it, but this is a thinly veiled lobbying effort to make us question the very business model of its competitors.
Apple needs to provide best-of-breed services and privacy, not second-best-but-more-private services. Many people will and do choose convenience and reliability over privacy. Apple’s superior position on privacy needs to be the icing on the cake, not their primary selling point.
It is nice that Apple sells products rather than eyeballs, but I don’t think this makes much difference for privacy. Google is not doing anything nefarious with the data. Apple is still collecting and storing tons of data that it deems “necessary,” and there’s no guarantee that it won’t somehow leak.
Update (2015-06-04): Nick Heer:
I’ve alluded to this before, but I’m not sure Apple can provide a Google-equivalent quality of cloud service while keeping things private.
Apple struggles with this kind of machine learning prowess because they don’t operate services in the same way that Google does. They don’t analyze user-provided data in aggregate; they often even keep a single user’s information siloed across multiple services.
It’s great that Cook so strongly pushes for privacy, but then Apple should kill iAds & block tracking by default, too.
Hacker News also has some comments about Panzarino’s article.
I’m going to give you a very cynical translation, which I don’t often do: We are in denial about how much better Google Photos is than what we’re doing at Apple. It is so advanced in terms of search that we won’t be able to match it anytime soon. In fact, we don’t even have anyone working on similar technology at all.
Update (2015-06-05): Cabel Sasser:
The (sad) core problem with Apple/Tim Cook’s privacy stance: nobody cares. If the alternative is free, better privacy is meaningless.
* nobody = 3% of some nerds care
A Thunderbolt 3 port will look like a USB-C port. They’re plug compatible. So if you plug in a USB-C device to a Thunderbolt 3 port, it should just work as you’d expect. And older Thunderbolt devices can still be used with Thunderbolt 3 via an adapter.
There’s also the issue of driving 5K displays. Intel’s announcements about Thunderbolt 3 mention that it supports DisplayPort 1.2, which can drive high-resolution displays, but doesn’t appear to have enough bandwidth to drive a 5K display via a single connection. (It can definitely do it via two cables.) The new DisplayPort 1.3 specification, which is being finalized, is supposed to support 5K displays via a single cable. It would be silly if a brand-new technology like Thunderbolt 3 shipped without the ability to drive 5K displays via a single cable, but that might be the case. We’ll have to wait and see.
Finally, there’s one other catch about Thunderbolt 3 adopting the USB-C connector: Room for confusion. You should be able to plug any USB-C device into a Thunderbolt 3 port without trouble. But if you’ve got a computer (like the new MacBook) that supports USB-C but not Thunderbolt, Thunderbolt peripherals (indicated by the lightning-bolt Thunderbolt logo rather than the USB logo) just won’t work (even though you can plug them in).
Commenters are saying that Thunderbolt 3 does support 5K displays via a single cable. I’ve seen on mentions on Twitter of various other minor caveats, but overall it sounds great to me.
Tuesday, June 2, 2015 [Tweets] [Favorites]
You use it as a labeled subscript, e.g. myArray[safe:3]. Subscripting + labels = ♥︎.
Well of course subscripts support labeled arguments!
Tim Bray (via John Gruber):
I’ve been writing this blog since 2003 and in that time have laid down, along with way over a million words, 12,373 hyperlinks. I’ve noticed that when something leads me back to an old piece, the links are broken disappointingly often. So I made a little graph of their decay over the last 144 months.
The attack, according to a blog post published Friday by well-known OS X security researcher Pedro Vilaca, affects Macs shipped prior to the middle of 2014 that are allowed to go into sleep mode. He found a way to reflash a Mac’s BIOS using functionality contained in userland, which is the part of an operating system where installed applications and drivers are executed. By exploiting vulnerabilities such as those regularly found in Safari and other Web browsers, attackers can install malicious firmware that survives hard drive reformatting and reinstallation of the operating system.
The attack is more serious than the Thunderstrike proof-of-concept exploit that came to light late last year. While both exploits give attackers the same persistent and low-level control of a Mac, the new attack doesn't require even brief physical access as Thunderstrike did. That means attackers half-way around the world may remotely exploit it.
As a general user you shouldn’t, in theory, be much worried with this bug more than you were with Thunderstrike. This is a bug more interesting to attack targeted users than mass exploitation, although a drive-by exploit is definitely feasible.
There are easier and cheaper attacks available against you the general user. As a reminder the latest Mac botnet infected around 17k users just by asking them for administrator privileges. Sophisticated attacks are not required when simple things still work.
Apple has quietly changed the way it promotes new and popular apps on the App Store, shifting from algorithmically generated lists to editorially curated content last month. TechCrunch reports that the “Games” section, for example, no longer has “New,” “What’s Hot,” or “All iPhone (Free & Paid)” categories, which have been replaced with editor curated lists such as “Best New Games” and “More Games You Might Like,” the latter based on a customer’s purchase history.
The report claims that some app developers have seen between 30% to 90% fewer organic app downloads since the changes were made, although the move away from automatically generated app lists is not expected to negatively impact most developers. In fact, editorial curation should help developers with truly useful apps gain some well-deserved exposure on the App Store, rather than clone or rip-off apps that sometimes slipped through Apple's old automated process.
Frustrated, last week I discovered something interesting. Searching around for info on the giant WindowServer memory leak I’d seen, I came across an Apple Support forum post describing the exact same problem! It had 189,000 views and 534 replies, so I knew I’d finally found something to soothe my MacBook’s suffering.
For those who are new to the Mac platform, zapping the PRAM is an age-old tradition that goes back to the classic Mac OS days. Even as a child, I was taught that when you had weird behaviour on your Mac it was time to zap the PRAM, which would promptly do nothing. Zapping the PRAM is number one on the list of desparate stuff to try on a misbehaving Mac that usually doesn’t fix the problem, outranking the trusty disk permissions repair and the perky newcomer, resetting the SMC. Zapping the PRAM is folk magic.
Monday, June 1, 2015 [Tweets] [Favorites]
Original implementation of @weakify and @strongify macros is complex because they accept more than one parameter. To make the analysis simpler, we’ll introduce our own versions, accepting only one parameter each:
#define weakify(var) __weak typeof(var) AHKWeak_##var = var;
#define strongify(var) \
_Pragma("clang diagnostic push") \
_Pragma("clang diagnostic ignored \"-Wshadow\"") \
__strong typeof(var) var = AHKWeak_##var; \
_Pragma("clang diagnostic pop")
In the block,
self is overshadowed by a local variable with the same name.
self can be used safely inside the block, because it references that local variable, which is held strongly, but lives only until the block ends executing.
Even the code not written by us can use
self safely, e.g.
With some OS X release (10.5, I think) Apple changed the format for crash logs on disk. I think they had been one file per app, and Apple switched to one file per crash. I had to write new code to handle the new format.
I made the change. It went to beta testers, who used the app extensively. Weeks passed. All good.
Then, on the day I released this version, I got a ton of reports from people who said, “It’s crashing on launch! But it works fine after launching it again.”
Update (2015-06-02): Mark Berstein:
If you do find yourself writing lots of
if(thing)... tests, though, you might be better off passing a Null Object -- a subclass of the expected class that does nothing, and does it quickly.
So, instead of checking, Tinderbox initializes views with an instance of NoLayoutPolicy. If a view is being constructed and isn't quite ready to do real work, we can still call Prepare() in perfect safety. If we’re about to disassemble a window, we can replace its layout policy with a fresh NoLayoutPolicy, confident that if someone tries to refresh the window we’re demolishing, there will be a NoLayoutPolicy standing read to do nothing.
Now, Apple has updated a technical document about how the heart rate sensor works. They are no longer saying that the Apple Watch reads your heart rate every ten minutes; instead, they say this:
Apple Watch attempts to measure your heart rate every 10 minutes, but won’t record it when you’re in motion or your arm is moving.
This is quite surprising. Why wouldn’t it take a reading when you’re in motion? After all, the goal of a fitness tracker is to motivate you to be active. This means that the Apple Watch cannot make any claim to realistically calculate your activity based on your heart rate.
Update (2015-06-02): Kirk McElhearn:
To many users, it looks like Apple pulled a bait-and-switch, promising a certain feature and not delivering it. Apple needs to say whether the change is because of faulty heart rate sensors – which means they have a bigger issue – or because of battery life. And if it’s the latter, they should allow users to choose whether or not the Apple Watch checks their heart rate every ten minutes. Let users decide how they want their battery usage to work.
However, if the heart rate sensors are faulty, simply turning them off, after promising this feature, is a mistake. They should fix them, whether through a software update, or by exchanging the devices. They promised a feature, and they can’t simply pretend that they never did so.
OSStatus.com (via Seth Willits) is a great resource for quickly looking up error codes. It supports not only the traditional
OSStatus error codes, but also
NSError codes from
NSPOSIXErrorDomain (errno.h), etc.
Update (2015-10-04): Marco Masser:
This [LaunchBar] action uses osstatus.com to look up information about error codes on Apple’s platforms. This is useful if you’re a developer who wants to look up some error code or constant but you don’t know in which framework or in which header it is defined.
As a bonus, if you have Xcode installed (either as /Applications/Xcode.app or /Applications/Xcode-beta.app), the search results let you browse the related frameworks and header files directly in the respective SDK.