The Iconfactory’s BitCam is so well done. Makes me smile. Don’t forget to scroll through the about box.→ 2016/06/10 7:57 am
We published Core Intuition episode 236 today, discussing the recent App Store announcements and a listener question about offices. We wrap up with plans for WWDC.
There has been a lot of great blog posts and podcast episodes already on the App Store subscription change. I listened to Under the Radar 31 and the Release Notes special edition today and recommend both. The most confusion seems to be around what kind of apps are appropriate for subscriptions, where by “appropriate” I mean “what Apple will approve”.
John Gruber also follows up at Daring Fireball on this question:
Professional apps that require “a lot of maintenance of new features and versions” don’t fit either of those categories. Would Twitter clients like Tweetbot and Twitterrific qualify for subscription pricing? After talking to Schiller yesterday, I thought so. Now, I don’t know.
As I mention on Core Intuition, apps that have a backend service with obvious hosting and maintenance costs — a music streaming service, an invoicing web app, or a blogging platform, for example — are easier for users to understand as needing to be subscriptions. Twitter apps are an interesting example because some are pure clients to Twitter’s backend, but many increasingly have their own app-specific services like timeline syncing or push notifications.
For years Apple has allowed apps to use auto-renewing subscriptions. I had an iPhone app and companion web service that was approved by Apple for auto-renewing subscriptions, after I made the case for the service as a “cloud” archive. From section 11.15 of the App Store review guidelines:
Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
From my experience and listening to other developers, I’ve had the impression for a while that Apple would essentially reject most auto-renewing app submissions by default. While we still don’t know what “all categories” means in the new announcement, I expect it means that there will no longer be a kind of blanket rejection. Apple will still reject many apps as poorly suited for subscriptions, though, and maybe that’s okay for now.
(I’m conflicted on this point. John Gruber’s suggestion to approve everything and let the market decide is compelling and fits better with my instinct that the control should be in developers’ hands.)
“Subscription fatigue” is a real thing that I’ll occasionally hear from customers about. No one wants to pay $1/month to 40 different apps and services; it feels like a burden in a way that paying the same total price to just two apps at $20/month does not. Nevertheless, subscriptions are very powerful. Everything I’ve done over the last few years is to position myself to eventually have a recurring-revenue success.
California: don’t forget to vote today. Throughout the primaries I’ve made small ($5) donations to Hillary’s campaign to mark milestones, like last night clinching the nomination. But there are many, many delegates up for grabs today. Let’s wrap this up and unite behind the nominee.→ 2016/06/07 8:15 am
Now that I’ve mastered having an expensive gym membership that I never use, going to move on to having a co-working place I never work at.→ 2016/06/06 1:22 pm
This first post will cover input, i.e. request data. Fetching input from a request, ensuring it is the correct type, and most importantly, not crashing. These are common tasks that most web developers deal with daily. All of the frameworks have their own unique way of doing these tasks–Let’s see how they contrast.
There is some further discussion from fans of other languages in the comments. Overall I think the article was fair. I’m not sure about the focus on “crashing”, though. This seems like a carryover from pro-Swift arguments on the desktop or mobile, and it has less relevance on the web.
For some web apps, it might be fine to throw an exception on bad input data, since it’s caught automatically and returned as a 500 error. I wouldn’t call that a crash anymore than I would call it a crash for a Mac app to present a generic error dialog on unexpected errors.