Only taking my iPad Pro to WWDC

I’ll be in San Francisco for WWDC, although as usual in recent years I won’t be staying all week. While out there I’ll be attending AltConf and other events, recording a podcast or two, and catching up on some writing.

I probably should take my MacBook Pro to code on projects, but I never have time. And I’ve been working so much lately, I probably need a break from Xcode for a few days. So I’m going to travel light this time and only take my iPad Pro with me.

I used my iPad Pro often when working from coffee shops and libraries earlier this year. I think I have a pretty good sense of what I’m productive with on it. iPhone and Mac app coding is out, but email, chat, writing blog posts, and even light web site maintenance are all fine, and those are the kind of things I do while traveling.

That leaves podcast recording as the only question mark, but actually I’ve recorded every episode of Timetable using my iPhone specifically so that I could get used to recording away from my office. I wrote a few months ago about my microphone for Timetable. I’ll do the same thing when Daniel and I record our WWDC thoughts after the keynote, with editing on the iPad Pro.

I’m excited about the conference. I’m looking forward to catching up with folks, the news from Apple, and — because I won’t even have my laptop — a bit of a break from the stress of thinking I should be programming.

Most developers hope we get a Siri API, but I’m not sure they agree on what that means. It could be a native SDK or it could be a web-based API more like Alexa Skills. The latter seems to better complement Apple’s weakness in services.

→ 2016/06/10 8:48 am

App maintenance and subscription rejections

Jason Snell closed his first take on App Store subscriptions with a question about iPhone app maintenance vs. web services maintenance:

Whether Apple would actually reject a subscription-based app that doesn’t offer any functionality outside of itself, I don’t know. It sure wouldn’t be the first time there was a baffling App Store rejection. But does Apple really want to take the position that ongoing maintenance of a web service has value, but ongoing maintenance and development of an app does not? I don’t think it does.

As I wrote about in my post yesterday, users can more easily see the hosting costs for a web service. They’ve been trained by a decade of paying for web subscriptions. Maintenance for the app itself has some differences.

Think about how costs scale if an app becomes popular. A web service becomes expensive to run, often thousands of dollars each month. You could say that a developer’s time for app maintenance is also thousands of dollars, but it’s essentially fixed. Outside of customer support costs, the incremental cost to a developer for an app doesn’t increase in the same way it does for scaling a backend service.

I hate that Apple has the power to reject our business model for a potential app. I’m now leaning more to the idea that Apple should approve nearly everything and let customers decide on the value. But there is a difference between maintenance of an app vs. a web service, and the services that are clearly appropriate for subscriptions will be the most successful apps using this new model.

Core Intuition 236 and app subscriptions

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

Tried Luxe yesterday instead of parking downtown for lunch. Worked great. I could get used to this… along with Uber, Instacart, Amazon Prime Now, etc.

→ 2016/06/03 11:05 am

Swift server benchmarks

Interesting Swift web server article comparing Vapor, which I tested last week, to other web server frameworks:

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.

Finals game 1 tonight! We published Technical Foul episode 7 — “Regression to the Mean” — wrapping up the conference finals, what worked for the Warriors, and predictions for Cleveland vs. Golden State.

→ 2016/06/02 8:53 am

Core Intuition’s 8 years and overselling WWDC

It’s 2 weeks before WWDC, which means it was also 8 years ago that we published the first episode of Core Intuition. At WWDC that year, Apple showed off iPhone OS 2.0, MobileMe, and the iPhone 3G. The yearly cycle of improvements to the OS and hardware don’t look much different today, but Apple keeps rolling, and so the total changes since 2008 are massive.

For as many years as I’ve been out to San Francisco for WWDC (and to San Jose before then), each year I have fewer expectations for the conference itself. Some years I don’t even bother guessing or dreaming about new features — I have no pressing needs, no critical missing APIs, no questions to ask Apple engineers in the labs — and I’m happily surprised by whatever Apple gives us.

This year is a little different. It’s the first year that I can remember since the Mac OS X 10.0 and 10.1 releases where an Apple platform needed significant performance improvements to be usable for anyone except early adopters. The first couple versions of Apple Watch were ambitious on features, but now it’s time to do the less glamorous work of making the platform fast. I hope watchOS 3.0 will be the same kind of milestone that Mac OS X 10.2 was in that regard. (And like Mac OS X, I hope it can be done mostly in new software.)

Back to WWDC the conference. I’m still thinking about the interesting venue change for Monday to the Bill Graham Civic Auditorium.

In the discussion on Core Intuition 229 last month, I kept coming back to the idea that this change has to be about growing the conference to allow more developers. Since more people show up on Monday (press and business folks, for example, who have less interest in the technical sessions or labs), you could have a bigger space on Monday and then oversell the conference as a whole, knowing that some ticket holders wouldn’t be around later in the week back at Moscone West.

Maybe that creates more problems than it solves because of packed rooms and long lines to get into sessions, though. Now that I’ve had a while to think about it, it seems unlikely that Apple would risk making the conference worse just to squeeze in another 500 developers.

Could there be some creative layouts in Moscone West that Apple hasn’t tried yet? There are so many downsides to changing the venue that I want to believe it’s part of addressing the biggest issue with the conference: most people don’t win the ticket lottery.

There’s still the problem of hotels. Linking to my post about not giving up on WWDC, John Gruber singled out Airbnb as a bad solution, since there just aren’t that many rooms available. That’s true. And even worse, potential last-minute cancellations make Airbnb less reliable. Where I said Airbnb, I should have just said “cheaper hotel”.

(Alex Cash also has tips for saving money at WWDC. Casey Liss has a good post about rising hotel prices.)

Nevertheless, I know some developers are using Airbnb this year, and I’d like to try it next year for a change of pace and scenery away from the conference. With the convenience of Uber, the risk of settling for a place farther away seems low.

And finally, I’ve enjoyed many recent podcasts about WWDC. Two highlights: Under the Radar episode 24, where Marco Arment and David Smith share their thoughts on whether to attend the conference; and Thoroughly Considered 12, about not just WWDC but the value of attending or exhibiting at conferences as a company.

Core Intuition 234 and Vapor

We published Core Intuition 234 today, with a follow-up discussion on Swift, working toward software releases, and more. From the show notes:

Daniel and Manton talk about the question of Swift’s dependence on Objective-C’s dynamism, how it should or will evolve, and their differences in philosophy about Swift and Objective-C. They also take stock of release discipline and managing customer disappointment with an app’s progress. Finally, they talk about the importance and difficulty of winding down old products.

One of the points I brought up on the show — and which I’ve hinted at here on the blog before — is that web developers will push Swift to become more dynamic. There’s a long history of building web server frameworks like Ruby on Rails that depend on dynamically routing requests to controllers and views, and flexible models that automatically adapt from your database schema. These features tend to get messy when faced with a more static, strongly-typed language.

There is good work being done in the Swift web community already, though. Today I spent some time building a sample app with Vapor, which is probably the closest I’ve seen someone get to the usability of existing web frameworks. I’m a little more optimistic now that we might eventually have a single language for server code and native apps.

NSDrinking is on for this week, Thursday 8pm at Radio Coffee & Beer. Come join us for a coffee or beer (or tacos!) and chat about iOS development and WWDC, which is less than 3 weeks away.

→ 2016/05/25 4:24 pm

Listening to Timetable

Because episodes of Timetable are short (usually just 5 minutes) and because they aren’t published on a consistent schedule (sometimes once a week, sometimes 3 times a week), I’ve wondered if it may be difficult for some people to fit the podcast into their routine of listening to longer, hour-long podcasts. If you only listen to podcasts while in the car, for example, a 5-minute show isn’t going to fill your commute.

Luckily there are easy solutions to this. The first is: they are so short, just listen whenever you want, while you’re at your desk or walking somewhere or having lunch. Another option: gather up a few episodes and listen altogether, as if it’s 3 parts of a 15-minute podcast.

If you’re an Overcast user, you can create a playlist that will play multiple Timetable episodes in sequence without requiring any tapping in the app to queue up the next one. Here are some screenshots showing one way to set this up after subscribing to Timetable in Overcast.

First, tap the new playlist button in Overcast. Then tap Add Podcasts and select Timetable.

Overcast screenshots

The playlist should automatically show any unplayed episodes. Finally, tap the Playback button while an episode is playing and make sure to highlight Play Next for the When Episode Ends option. This will make sure that you have continuous playback from one episode to the next.

Overcast screenshots

I’ve recorded 23 episodes of Timetable so far, equal to about 2 hours of audio. While consistency is the most important thing for my other podcasts, Core Intuition and Technical Foul, for Timetable I’ve liked the flexibility to experiment with different styles and show formats. Enjoy!

Two months since the iPhone SE first shipped, it’s still rarely available in stores and ships in 2-3 weeks. Best phone I’ve ever owned.

→ 2016/05/23 3:38 pm

Swift and sharp knives

David Heinemeier Hansson has a great post today about Ruby’s advanced dynamic features. Some people would criticize Ruby (and Rails) for including “sharp knives in its drawer of features”, but David argues that it’s a worthwhile tradeoff to give developers such power and flexibility:

There’s nothing programmatically in Ruby to stop you using its sharp knives to cut ties with reason. We enforce such good senses by convention, by nudges, and through education. Not by banning sharp knives from the kitchen and insisting everyone use spoons to slice tomatoes.

Given the recent discussions from the Apple community, I couldn’t stop thinking of Swift as I read David’s post. I wouldn’t go as far as saying that Swift is a dull knife; there is a lot to like about the language, and I feel reasonably productive in it now. But David’s “paternalism” line nevertheless rings true to me, that the Swift compiler is trying to protect us from ourselves.

New Core Int, Technical Foul, and Timetable

I somehow recorded 4 podcast episodes this week. We just published episode 233 of Core Intuition, where Daniel Jalkut and I talk about the announcements from Google I/O and compare the latest Swift 3 news to our experience going through previous Apple transitions. From the show notes:

“Manton and Daniel react to Google’s I/O keynote, and weigh the threat of Allo to iMessage. They celebrate Apple’s WWDC promotion of 3rd party events, and the increasing speed of App Store reviews. Finally, they reflect on the announced delay in Swift 3’s planned ABI stability, and Daniel’s sudden FUD about embracing Swift.”

It was a big week for the NBA, too, with the first couple games of the east and west conference finals. On the latest Technical Foul, Ben Thompson and I recap round 2, especially the Spurs loss in 6 games to the Thunder:

Ben and Manton are back geeking out about the NBA. This week we talk Manton through the Spurs loss, discuss OKC versus the Warriors, and whether the Cavs are good enough.

And finally, I published 2 episodes of my microcast Timetable earlier in the week. Episode 22 was about dealing with recent stress — trying to see the bigger picture and focus on the good things. Episode 23 was about how to tell when it’s time to move on from a failed product.

Wanting an open voice assistant platform

I’ve owned an Amazon Echo since it first shipped and it’s great. I also use Siri and like it, though I use it less often for the kind of random questions I might ask Alexa. But after watching yesterday’s Google I/O keynote, I can’t help but feel that eventually Google is going to be far ahead of Amazon and Apple in this space.

Here’s John Gruber writing at Daring Fireball about the keynote:

Google is clearly the best at this voice-driven assistant stuff. Pichai claimed that in their own competitive analysis, Google Assistant is “an order of magnitude” ahead of competing assistants (read: Siri and Alexa). That sounds about right.

The problem with a voice assistant is that the better it gets, the more you want it to do. You continue to ask it more complicated questions, pushing at the limits of the assistant’s capabilities.

Only Google has the expertise in web services and the massive amount of data to keep going beyond basic questions. I expect both Siri and Alexa will hit brick walls that Google will get past, especially in conversational queries that let the user drill down below the most popular, superficial facts.

That is, unless Apple can open up Siri. Not just plugging in new trigger keywords like Alexa’s “skills” API (which would be a good start), but maybe a complete way to extend Siri with third-party code that feels seamless to the user. Surfacing voice-enabled apps automatically through natural queries might be on the same scale of app discoverability as we saw when the App Store launched.

As Ben Thompson lays out well in today’s essay, Google faces a different internet than the open web on which they built their search engine. The default for all these new platforms — from Facebook to Siri to the App Store — is to be closed. There’s a narrow window, right now, for someone to take the lead on creating an open voice assistant standard built on the open web.