Archive for June 8, 2016

Wednesday, June 8, 2016

New Sketch 4.0 Licensing Model

Bohemian Coding (tweet, Hacker News):

Until now, it has been our custom to release a major version of Sketch (2.0, 3.0, etc) every couple of years as a paid upgrade, with minor updates (3.1, 3.2, etc) for free in between. While this is a very common model for software, we don’t think it is fair: customers who have purchased an app closer to the original release date get free updates for longer than someone who bought the same product halfway through its release cycle. We think a fairer approach is for everybody to get the same period of free updates, no matter when they purchased the app.

We would also prefer to ship big updates and improvements frequently, when they’re ready, rather than waiting for the next major version to come around in order to entice people to upgrade. As a consequence, we intend to remove the distinction between major and minor releases altogether.

They are essentially doubling the price from $99 every two years to every one year, but it’s not really a subscription because if you stop paying you can keep using the version that you have.

Pre-WWDC Thoughts

Chris Adamson:

The only good desktop Mac available today is the top-of-the-line iMac. Everything else is a goddamned embarrassment: terrible values for the price and clearly products of neglect. In fact, I noticed yesterday that Ramjet is now offering tower-style Mac Pro 5,1’s retrofitted with new CPUs and 1 TB SSDs, and they are arguably more compelling than Apple’s brand-new Mac Pros (and cost $2,000 less!). It takes you back to the days when Power Computing’s Mac clones made a mockery of 1995 Apple’s Performas and 5000-whatever models.


Shazam and Twitterrific are best-of-breed apps on the iPhone, but their Watch apps are straight-up non-functional. Do we think the developers suddenly lost their mojo, or is it that the Watch APIs and internal systems simply do not work reliably enough to build third-party apps atop?

Andrew Cunningham:

Of those, the MacBook and the iMacs are both fine; they were updated fairly recently and there’s not a whole lot you could change about either machine with current technology. But the “Pro” machines especially are notable in a bad way. Mac designs have always lasted for longer than iPhone and iPad designs and Apple’s release schedule is at least partially determined by Intel’s, AMD’s, and Nvidia’s, but that’s a long time to go without revisiting designs.

Rumors suggest Apple will be paying some much-needed attention to its Mac lineup later this year, possibly at WWDC and possibly in the months after. In the meantime, let’s walk through features Apple could add to the platform and things it could change about individual Macs to keep pace with and get back on top of the industry this company once led.


A totally redesigned Mac Pro was announced with much fanfare at WWDC in 2013, three years after the old “cheese grater” Mac Pro got its last significant update.

Jason Snell:

Reverting back to calling the Mac operating system “Mac OS” is high on my wish list. I’d prefer that particular style to some newfangled “macOS”, but I’ll take that if it’s the only way to get the Mac back in the name of the operating system that powers it. I’d like the “X” consigned to the ash heap of history. I’m okay with the idea of place names continuing as the monikers for Mac OS releases, but I’d prefer Apple just go to sequential numbering as it has with its other platforms—starting with Mac OS 11 this fall.


More importantly, it’s way past time for both the Mac Pro and the MacBook Pro to receive updates. The Mac Pro hasn’t been updated in ages, to the point where it’s actually embarrassing that Apple’s still charging full price for such old technology.

Steven Frank:

WWDC pipe dreams: fix Finder, fix iTunes, fix App Store, stop iOSification of Mac OS, pro hardware with top-end specs and ports intact

John Siracusa:

…and a new file system.

Mark Sullivan:

Perhaps most importantly, Apple is likely to finally release a software development kit (SDK) to developers so that they can integrate Siri into their own apps.

Rohan Naravane:

In an attempt to keep the user experience in check, Apple has always given its own apps the first priority. For example, a hyperlinked email address in a messaging app when clicked, will open the Mail app, and not Gmail. Or when a location is shared on WhatsApp, it is Apple Maps that opens up by default, not Google Maps. Although past experience doesn’t suggest Apple will let people choose their default app preferences, letting Siri roam beyond the walled garden can provide 3rd party apps a level playing field at least with voice control.

Here are five things I’ll be glad to say to Siri once developers are given access, effectively bypassing some of Apple’s mediocre service offerings.

Nick Heer:

Of all the things I wish to see at WWDC next week, improvements to search — across the board — rank highly on my proverbial list. The company has come a long way in a very short period of time, but search still isn’t good enough; searching on both the App Store and Maps, in particular, remain among the most frustrating experiences on any of Apple’s platforms.

Dan Moren:

We spend a lot of time navigating through the lock and home screens on our iOS devices, and rather than them just being way stations for us to pass through en route to our apps, it’d be great if they offered a little more utility along the way.


Cut, copy, paste and text selection was missing for a long time on the iPhone. Those text-handling features didn’t arrive until iOS 3, but they’ve remained largely unchanged since then. The problem is that they’ve become increasingly finicky. Trying to select just the portion of a web page I want to copy has turned into a battle for me, trying to seize one of those blue text-selector handles and not having it snap away because the software thinks it knows what I want.

Jason Snell:

iOS needs to handle files better, specifically on external drives. I should be able to attach an SD card (or even a USB hard drive) full of files to my iPad Pro and import the files I need; right now, if it’s not a video or audio file, I’m out of luck.

Gus Mueller:

A Mac OS upgrade which is about bug fixes and minor features. Maybe even moving to an 18 month upgrade cycle instead of a yearly one.

Erica Sadun:

My answer is the same as it’s been for years: “Bug fixes and security enhancements.” I’m a bit over the yearly update cycle.


I’d just like an Xcode, tool-chain that actually works.

As for me, the number one thing I want from WWDC is for Apple to focus on fixing bugs (in the OSes, apps, services, and Xcode).

Update (2016-06-09): Tim Schmitz:

WWDC kicks off in just a few days, which means it's prediction time. This year I've got one that's a little off the wall: Not only will there be an API for Siri, but it'll be iCloud-based and take advantage of Swift on the server.

Swift Configuration and “then”

Soroush Khanlou:

I toyed around with a few ways to fix this issue, including making the instance variables optional and filling in the defaults at the usage site, but that ended up being just as clunky as the big initializer. What I settled on was: instead of making the variables optional, I made them mutable. That solves quite a few problems.


The then extension is a really useful library to have in your app. […] Since everything in Cocoa Touch inherits from NSObject, you can now use this function to configure lots of types, and you can do so at the declaration of the property. Swift will let you initialize things in-line (as long as they’re effectively a one line expression) […]

Swift Mistakes

Zev Eisenberg:

Even though I’ve been keeping up with Swift blog posts, my first Swift app was a port of an old and crusty Objective-C code base, and I carried over a lot of old habits. In looking back over it, I found many small- to medium-sized changes that make the code cleaner and more Swifty. Maybe I can help you avoid similar mistakes.


Sadly, you can’t make protocol conformances private, but otherwise you should be using private extensions wherever you aren’t required to make them public.


There are certainly cases where direct comparison to nil are appropriate, but Swift’s language features make it pretty rare in my experience.


Since you can extend any type, it’s convenient to make extension files for your utilities on CGRect, CGPoint, UIInterfaceOrientation, and other types that couldn’t be extended when they were lowly C structs. So don’t litter your main code files with one-off domain-specific utilities on system types. Put them in a separate file and write a couple of unit tests just for that file.

Daniel Jalkut:

At first, I didn’t think too much of this bridging header. Sure, I want to access my Objective C files from Swift. Which ones? Why not all of them?


My takeaway is to accept that it is fundamentally unsafe to interface with Objective C classes whose headers have not been audited for nullability.