Archive for August 10, 2017

Thursday, August 10, 2017

Ulysses Switches to Subscription

Marcus Fehn (Hacker News):

As of today, we’re changing Ulysses’ payment model. It’s still the same Ulysses, same features, same distribution, we’re just switching to subscription. For $4.99 per month or just $39.99 per year, you can now use Ulysses on all your Macs, iPads and iPhones, including sync. You no longer need to buy two separate versions for either platform – from now on, it’s just Ulysses, and you can use it wherever you want.


We can finally offer a free, cross-platform trial. Ulysses can now be downloaded and fully tested for 14 days, on all devices, including sync, no price or strings attached.


We are offering all our current customers a lifetime discount on Ulysses’ yearly plan (it’s 50% off the regular monthly subscription).

As with other recent switches to subscriptions, the Ulysses change seems to be accompanied by a price increase. The subscription is $40/year, while previously the Mac version was $45 and the iOS version was $25.

The FAQ:

Both the monthly and the yearly subscriptions are auto-renewing.


With the change to subscription, we changed the versioning scheme to better match the new model. We’re now increasing the version number for each new feature release. Ulysses has had 10 feature releases (1.0, 1.1, …) so far, so this is the 11ᵗʰ feature release. The next feature release will be version 12.

Max Seelemann (tweet):

I am not exaggerating in saying that this was the hardest decision in our whole time as professional software developers. After all, we have a system which currently works — after 14 years we are still around, Ulysses is still “a thing”, it’s even going better than ever before, and there are no immediate signs which hint at a change coming soon.


If you bought Ulysses at its launch in April 2013, you will now have received nine major feature releases. For free, at no additional cost. At least 80% of that originally purchased app have since been scraped and replaced. Its functionality has quadrupled during the same time.


In-between such big point-releases, sales will often drop to a non-sustainable level. So it’s not that we’re getting rich during the development period, and even richer after each update. No. We’re actually loosing money during development. And so the longer it takes to ship an update, the riskier it becomes financially. We are, in fact, highly dependent on these sale spikes, in order to make money.

He doesn’t think upgrade pricing is the answer, in part because the way people update their devices has changed:

It’s perfectly obvious that the overall situation is the same for paid updates as for one-time purchases. The situation is less severe than with the paid-once system — the sales spikes after bigger releases will be much higher –, but after each release, sales will fall back to a similar level.


And let’s just say you don’t update. You simply stay on the previous version, because you don’t think you need the new features, or because you find the update price not worth it. How long will this very version continue to work? On the same device and the same operating system… probably “forever”, sure. But does that really hold nowadays, when people get new phones every two years and OS updates are free?


Ulysses, for example, had critical bugs on every new version of macOS and iOS that came out since we launched in 2013. Yes, we fixed them immediately, but the next device, the next OS, will break some stuff again. The old app will break eventually, there’s just no way around it. As soon as the user’s environment changes, old stuff breaks.

And with the iOS version only available via the App Store, there’s no practical way to stay with an old version—and a newer iOS version may not be able to sync with an older Mac version.

See also: MacRumors (forum), 9to5Mac, John Gruber, Shawn Blanc, Michael Rockwell, Adam C. Engst, Ben Sandofsky, Dan Counsell, Dr. Drang, Wojtek Pietrusiewicz, Joe Cieplinski, Charlie Sorrel, Alex Cranz, Matt Gemmell, Dan Counsell, Eddie Smith, Matt Gemmell, Core Intuition, Gopal Sharma.

Update (2017-08-14): Max Seelemann:

Adding subscription to Ulysses took us 7 months, with 1 man-year engineering, 1.5 man-years total effort. It’s 22k lines of production code.

It feels like most of that should have been handled by the App Store. So. Many. Pitfalls. Everywhere.

Update (2018-04-20): See also: ChartMogul.

Update (2018-08-31): Max Seelemann:

The amount of pain we’re going through by trying to run a cross-platform subscription business without accounts is mind-boggling.

I hate accounts, but for us that’d certainly have been faster and more reliable.


No detail yet (ask Macoun 😉) but essentially we’re syncing receipts through iCloud.


We also didn’t want to have them, as that’d leave the impression we’d also have user’s data. Which we never wanted to have. And it would still feel weird today. Data and license syncing through two different system...

Why Apple’s Glasses Won’t Include ARKit

Matt Miesnieks (via Peter Steinberger):

I know glasses are being worked on at Apple, and the prototypes are state of the art. I also know what it takes to build a full-stack wearable AR HMD, having built fully functional prototypes from scratch. There are a bunch of elements that need to work before a consumer product can exist. These elements don’t all exist today (even at the state of the art).


ARKit is a big deal for the AR industry. Not just because it’s got Apple’s marketing fairy dust, but because it means that developers now have a high quality “6dof pose” to use in AR Apps. Everything in AR is built on top of a high quality pose. Solid registration of digital assets in the world. Indoor & outdoor navigation. 3D reconstruction algorithms. Large scale tracking systems. Collision & Occlusion of digital & real. Gesture detection. All these only work as good as the pose the tracking system provides. My earlier article explains more about how Apple did this & how it all works.


The most important advantage re the Glasses is that Apple has Marc Newson on the team. Look him up if you don’t really know who he is. He knows how to design cool glasses. One lesson I learnt at Samsung, is that Industrial Designers view glasses as one of the most difficult physical products to design, mostly because everyone’s face shape & taste is different, and there’s physically almost nothing to them (ie can’t add features to keep everyone happy, the design has to be very pure & simple).

Taking Uber to Small-claims Court

Joe Mullin:

The Uber car was squeezed into the narrow Boston street between other cars, and Wilcox had to shimmy out. So he hauled out just the suitcases, telling the driver he’d be back in a minute to grab the backpack. But when he reached the curb, the Uber car immediately drove off with his backpack still sitting in the back seat.


At that point, Wilcox went to the police and filed a report. He had the driver’s first name, a picture of him from the Uber app, the car’s license plate number, and confirmation of his ride details.


When Wilcox finally got the police report, it contained a big surprise. Uber had stonewalled Wilcox but emphasized—in court, in phone conversations, and in public statements—that it always cooperates with law enforcement. Yet the police report showed that Uber maintained the ride hadn’t even taken place […]

The investigating police officer made multiple visits to the address on record of the vehicle’s owner, but no one had answered. Uber, meanwhile, said the driver hadn’t worked for them for two years.

See also: Wilcox’s blog post.

Mixing Constant and Literal Strings in Swift

Joshua Emmons:

And now we have an interesting decision to make. Do we want to enforce safe, well-known constants and provide an option to specify arbitrary strings? Or do we want to allow arbitrary strings and provide an option to specify safe, well-known constants?


Situations come up all the time where we need an “escape hatch” from our carefully calculated set of pre-defined options.

When that happens, we don't need to throw our hands up in despair and make everything a String. Enumerations (combined with CustomStringConvertible and maybe even ExpressibleByStringLiteral) let us work around the 20% case while not jeopardizing the safety and convenience of the 80% out there.