Craig Hockenberry:
To everyone who thinks the Mac App Store makes installing updates quick and easy[…]
Intuit:
Quicken Mac 2015 updates are no longer distributed via the App Store. To install the latest version of Quicken Mac 2015 if you purchased from the App Store, you need to download Quicken Utility, which will install a version of Quicken Mac 2015 that has the ability to install updates without using the App Store.
[…]
You may be prompted to enter an administrator user name and password. This is required to replace the application you installed from the App Store with the new version that was downloaded.
Craig Hockenberry:
And the root cause for this wonderful user experience: no paid upgrades on the Mac App Store…
Wil Shipley:
The point is you can’t add paid upgrades if you’re in the App Store, so Intuit had to leave or go bankrupt.
Quicken 2016 is a separate product in the Mac App Store, presumably so that it could be a paid upgrade. So it makes sense to remove Quicken 2015 from the store to avoid confusion. Then there is no way to ship updates via the store, so we get this 14-step procedure.
Craig Hockenberry:
Note that I had no idea that critical security updates were available because I relied on the Mac App Store[…]
With Quicken 2015 removed from sale, there’s no way for the store to notify customers. And Intuit can’t e-mail them because only Apple knows who they are. The Mac App Store version of Quicken could periodically check Intuit’s server for news about important issues, but Apple forbids apps from offering updates that are available outside of the store.
Jon Hendry:
Best not to buy a tax app from the store, in case it goes unusable April 14
Indeed.
Update (2015-11-24): Wil Shipley:
You’ve created a marketplace that actively punishes developers for maintaining their software[…] You are losing the innovators. You are losing the developers who are actually loyal to your platform.
Daniel Jalkut:
Not to say that Apple losing in this scenario means that developers win. It’s a lose lose, unfortunately. Who loses most? Uncertain.
Chris Hisle:
the answer is always the customers. They lose the convenience of the App Store or access to high quality apps
Update (2015-11-25): I want to be clear that I’m not criticizing the way Intuit’s updater works. It looks like it’s about as straightforward as could be. You essentially download an app, launch it, and then follow the normal Sparkle prompts. The large number of steps is because the instructions are very clear, which is a good idea because customers following them may not be familiar with how to download apps outside of the Mac App Store.
Business Intuit Mac Mac App Mac App Store Quicken
Rachel Worthington:
With this in mind, the model that I thought would be best for me, would be a git repository on the server, and a git repository on my laptop where I like to write. I could then make changes locally, commit them, and push them to the server repository, where they would magically appear, so that hugo could run over them and re-generate my website.
Rachel Worthington:
My mysterious error also suggested a setting could be used to override this safe-guard, (the recieve.denyCurrentBranch setting) and indeed it can.
[…]
The initial error, about updating the current branch of a working copy is denied because it will make the index and and There is a way to make the setup I wanted, and I was most of the way there. The rest of the way would have involved setting up a post-recieve hook to run git reset --hard on the repository after the push. This would have kept the working copy win sync with the rest of the repository, allowing the working copy to update, whenever an external push happened.
It looks like there is also a newer way:
git config receive.denyCurrentBranch=updateInstead
[…]
Update the working tree accordingly, but refuse to do so if there are any uncommitted changes.
Git Syncing Version Control
Christopher Phin:
Power Goo’s features—the ability to smear regions of an image around and paint bits of one photo onto another to create composites—seem unexceptional today, but in the ’90s, this was mind-meltingly exciting stuff, not in and of itself maybe, but in how easy and fun Power Goo made the process.
Just look at that interface! That’s the thing I remember about Power Goo at least as much as the images you could create with it. It really felt for a few years that this was how software might look in the future: not staid, rectilinear, essentially monochrome buttons and menus, but big, juicy, floating 3D buttons and big, exciting levers that you pull to change variables. It was a future that lots of people thought was horrendous, of course—silly Fisher Price exuberances getting in the way of your work—but after decades of the command line and the established modern GUI conventions, it was at the very least new, and I’d argue intoxicating too.
See also: Bryce 2, Kai’s Power Tools 5.
Design Graphics History Mac Mac App MetaTools
Brent Simmons:
Back in the ’90s I shipped SpotLight, a search engine that ran on Macs running WebSTAR (http server), FileMaker Pro (database), and UserLand Frontier (scripting system).
It was the closest thing I had to success at the time, but it was still a failure. It sold just 10 copies.
But it was 10 copies at $99 each, and people paid with a check, so I made exactly $990.
[…]
It seems like such a small and cute amount of money. But it occurred to me just today to figure out how you’d get there on the iOS App Store.
App Store Business History iOS Mac Mac App
Joe Groff:
Unowned is faster and allows for immutability and nonoptionality. If you don’t need weak, don’t use it.
unowned uses a second refcount in the object. weak refs are tracked in a global table.
It’s a space/time tradeoff. unowned can’t free memory until unowned refs die, but weak frees immediately when strong refs die.
Yeah, so we can check whether the object is still alive before strong-retaining it again.
The object is destroyed and gives up all its resources when the last strong reference is released.
The memory for the instance is still allocated but left in a zombie state.
This is so that Swift can guarantee that if you try to access it you get an error rather than a crash or the wrong data. If you don’t want that overhead:
There’s unowned(unsafe), which is completely unmanaged.
With weak references, the memory can be freed immediately. This is safe because the references are zeroed, but it’s more cumbersome because you have to deal with optionals.
Automatic Reference Counting (ARC) Language Design Memory Management Optimization Programming Swift Programming Language Swift Runtime
Sam Marshall (comments):
Most of you are probably familiar with the fact that Xcode uses NeXTSTEP plists for the format when serializing project files.
[…]
Xcode’s implementation of deserializing the NeXTSTEP plist files is different from that of what is used in (Core)Foundation. There are assumptions made about what the output encoding is assumed to be, as well as supporting writing out this format of plist when (Core)Foundation does not. The NeXT/OpenStep plist format assumes that strings are written as ASCII, whereas Cocoa assumes strings are written in Unicode. As a result, Cocoa will happily read unescaped Unicode data from NeXT/OpenStep plists (while the parser will fail to read properly escaped sequences longer than 4 digits). This makes the format invalid as it is no longer ASCII data on disk, however will still be parsed correctly by classes like NSDictionary because of Cocoa's assumption that all strings are Unicode.
Cocoa History Mac Mac OS X 10.11 El Capitan NeXT Programming Unicode Xcode
