Category Archives: Programming

Swift 3 churn

Back in July, I posted this to my microblog, which was cross-posted to Twitter for some additional discussion:

Not shocked that Swift classes won’t be subclassable by default. But it underscores Swift’s priorities. And for that reason, I’m out.

The “I’m out” was meant as a Shark Tank reference, and not to be taken too seriously. But I was serious about taking a break from Swift until version 4, when it would at least be more stable. Daniel and I followed up that week with a more in-depth discussion on Core Intuition 242.

A few days ago Craig Hockenberry posted about how the rapid pace of improvements to Swift can get in the way of learning the language and using example code:

It’s gotten to the point where every time I come across some information written in Swift, especially on Stack Overflow, I cringe. I know that I’m going to have to not only figure out the code, but also which version was used for the answer.

I have absolutely no regrets sticking to Objective-C. As Swift 3 was wrapping up, it seemed that the churn around syntax changes was even worse than I feared. From an Apple dev forums thread at the time:

For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions–at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes.

That settled down with the final Swift 3 release, but I expect many developers won’t upgrade from Swift 2.3 until Xcode forces them to. There’s even a whole book by Erica Sadun on migrating code.

I still consider Swift a beta language. I just hope that the Swift team and community recognize that this level of instability isn’t acceptable forever. A programming language is not an iOS or macOS release. There shouldn’t be a new major version of Swift every year.

Workflow update for web APIs

Federico Viticci has an overview and examples for the latest Workflow for iOS release, which adds more advanced features for calling into web APIs. It looks great:

For those who are only partially familiar with the terminology, this means that Workflow can communicate with the majority of modern services that come with a web API. If you’ve never worked with web APIs before, it’ll take you a few hours of reading and experiments with dictionaries, token authentications, form requests, and file uploads to get the gist of how it works. But, the Workflow team has managed to make what tends to be a visually unintuitive programming task – assembling dictionaries and structuring JSON – as simple and attractive as possible, abstracting many of the complexities that web developers have to deal with in desktop IDEs and command-line tools.

Here’s another nice example of automatically creating GitHub Gists, from Jordan Merrick:

This is a workflow I’ve always wanted to create, and the new API support makes it possible. Gists are great to share small pieces of text information, such as code snippets or scripts. This action extension workflow accepts files of any type (though they must be text-based) and creates a gist using the GitHub API.

Workflow can now take over many web tasks that previously required either writing scripts or depending on hosted solutions like IFTTT and Zapier. Like my workflow for posting photos to my blog, it’s a natural tool for web publishing and microblogging.

I’d also love to see a Mac version of Workflow one day. I do some limited automation on my Mac, but AppleScript and Automator aren’t as easy to use or as well-maintained as Workflow.

Rewriting in Rails 5

I’ve been doing Ruby on Rails work again. Although my indie web projects are all Sinatra, I generally recommend to clients that Rails is the way to go. Rails will be easier for them if someone else ever needs to take over the project.

I don’t like using 2 products that do the same thing, though. That’s why I consolidated my web app hosting to Linode, and my source code to GitHub. Why should I switch between 2 frameworks, especially since Rails has matured so well? I’m enjoying Rails 5.

David Heinemeier Hansson said in an interview on Slashdot, about the rise of JavaScript front-end frameworks:

But it seems like that’s one of the lessons people have to learn by themselves. Just try to string things together on your own a few times and you’ll quickly get an appreciation for what Rails provides as a backend framework. We’ve had tons of programmers try just that and come back for refuge.

It struck home because I’ve had some regrets with choosing Ember.js for my new app. Part of that is my own lack of experience with the framework. But also I’m no longer convinced that the heavily JavaScript-based view layout of something like Ember.js is better than Turbolinks, for example. I plan to rewrite my app in Rails and more classic Ajax at the earliest opportunity.

Mac App Store developer survey

DevMate surveyed 679 Mac developers to put together a report on who is using the Mac App Store vs. selling direct, what concerns developers have, which tools they use, and more. On why developers leave the Mac App Store:

If you’re thinking giving away 30% of your hard-earned revenue is the deal-breaker, you’d be surprised. Revenue share is not the main reason developers flee. The main reason is the long and unclear App Review process, closely followed by revshare and the absence of trial versions.

While sandboxing does show up on the complaint list, it’s ranked low as a reason to not use the Mac App Store, even though it was why I pulled my app Clipstart from the Mac App Store 4 years ago. And not much has changed since I wrote about Sketch and other apps leaving the Mac App Store last year.

For anyone who has been following blog posts and conference talks about the Mac App Store, there won’t be many surprises in this new survey, but I found the details interesting. The survey appears to be a good snapshot of how the Mac community is feeling about selling software.

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.

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.

Apple’s mindset on Swift dynamic features

I let myself go off into a bit of a Swift rant on the latest Core Intuition. I’ve been doing a lot of Swift development recently. The more I use it, the more conflicted I am. I really love some parts of the language, but it’s not what I would have asked for as a successor to Objective-C 2.0.

Remember when Steve Jobs came back to Apple and compared NeXTSTEP to constructing a building by starting out on the 20th floor, with so much of the foundation and common patterns already taken care of for you? Cocoa allowed apps to be built significantly faster than before. Steve said at Macworld Expo in 1997 that the goal was to “eliminate 80% of the code that every developer has to write for their app.”

Swift is not like that. Swift’s priorities are correctness and stability. These have more indirect benefits to developer productivity than we saw going from Carbon to Cocoa.

When Marco Arment wrote about Swift last month, he mentioned wanting a language designed for high-level apps:

Objective-C wasn’t much better for this, but I think we could’ve done better than Swift if the most important goal in Swift was maximizing real-world developer productivity when writing modern Mac and iOS apps. Swift does a little of that, but gives up a lot to also serve lower-level, more clever, language-geekier goals.

This weekend, Brent Simmons has a new post about the loss of dynamic features in “pure” Swift:

What makes me nervous is Swift’s emphasis on type safety and on compile-time resolution. As long as we also have what we need from Objective-C, then that’s fine — then we still get xibs and storyboards, the Responder Chain, and so on.

I hope Brent’s right that this will be a core part of Swift 4. Leaning on the Objective-C runtime feels like a temporary solution because it only exists on the Mac and iOS. Great web frameworks like Ruby on Rails, for example, can’t be built without relying on a more dynamic language. (And to me a great promise for Swift is being able to use it everywhere.)

Daniel Jalkut followed up with a more optimistic post. He thinks Apple is on top of this, even as he acknowledges the clash between existing frameworks and the new language:

Some major design priorities of the Swift language, namely type safety and compile time dependency binding, are at odds with the design priorities of 20 years of evolution in Apple’s frameworks. How and if that disparity will be reckoned by Apple remains to be seen.

I think it’s telling that the “dynamic” keyword isn’t even mentioned in the main language guide. Anything related to Objective-C is off in a separate set of documentation, which includes discouraging statements such as “Requiring dynamic dispatch is rarely necessary” and “use of the performSelector APIs is discouraged”. For Swift to thrive in the future, as a great language for newcomers and long-time Mac developers, Apple will have to compromise on that mindset.

Navigation controllers on the Mac

Brent Simmons has a good post about the pros and cons of bringing UIKit to the Mac. On the differences between iOS and Mac development, though, one point did stand out for me:

And there are things Macs don’t have at all — navigation controllers, for instance, since they don’t make sense in a context where you can just show the hierarchy via multiple panes.

Brent’s right that most Mac apps don’t need navigation controllers. I don’t think I’d have any use for them in my Mac app, Clipstart, for example. But navigation controllers are becoming more common in Mac apps, starting with Twitter apps especially. I expect an important part of Iconfactory’s work on the Chameleon framework to bring Twitterrific to the Mac was supporting navigation controllers.

I’ll always consider myself a Mac developer first, even though most of what I do these days is on iOS and for the web. I’d definitely welcome UIKit for Mac. I’m getting closer to announcing a new iPhone app and web platform, and while I have a Mac version in development too, I can’t justify the time right now to finish it. UIKit for Mac would make that decision much easier.

Cute release notes

Ben Brooks takes on the trend of cute stories inside of release notes:

“With disturbingly increasing frequency, companies are deciding to let their marketing departments handle their release notes instead of the engineering team or product manager.”

I agree. These were fun at first, but the release notes don’t need to be entertainment. They should be a summary of what changed, with bullet points for key changes. (A single “bug fixes” line is also not helpful.)

I personally like to start each line with a clear statement: “Fixed <something>” or “Added <this feature>” or “Improved <something else> by <doing this>”. You can see this in the history of my Tweet Library release notes, for example.

Parse shutting down

Bad news from the Parse team at Facebook today:

“We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017. We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere.”

For years I had always heard great things about Parse. I eventually used it for the first time a few months ago on a client project. It’s got a well-designed API, friendly monthly pricing (free for many apps), and it seemed well supported, with new features like tvOS support and a web dashboard redesign rolling out just a month ago.

Thinking about this tweet from Daniel Jalkut, I’ve always advocated for iOS developers to also be good at web services. Customers expect sync everywhere now, and you can do things with your own server that will give you an advantage over competitors who have a simpler, standalone iOS app. But being forced to migrate server data isn’t fun, especially on someone else’s schedule.

Fin and split-view for Apple TV

Joe Cieplinski ported his iPhone timer app Fin to the Apple TV:

“Three weeks of spare hours here and there to get myself familiar with the HIG, the UI challenges, etc. was well worth the effort, as far as I’m concerned. And now I get to see if any of my users find the TV app useful, or if I pick up any new attention as a result of being there.”

Hearing stories like this, and thinking about my own apps, I’m convinced that the Apple TV needs split-view support like iPad multitasking. Our apps could be off to the side of the screen while someone uses most of the TV for watching shows or running another full-screen app. Just as I suggested that lightweight universal apps are okay, there is a class of apps that would become more useful when they don’t have to monopolize the entire TV.

iPad thoughts for 2016

Over the holidays, or while on any vacation, I usually use iOS more often than my Mac. It’s easier to quickly catch up on email or fun stuff like Instagram without getting too pulled away from what matters: spending time with family and friends. So as I use iOS, I’ve been thinking about what might make the iPad better.

Last year Jared Sinclair blogged about some of the problems with the iPad, with ideas for “saving” it. The most interesting of these was his suggestion of a “Gatekeeper for iOS”, where iOS apps could easily be side-loaded onto iOS without Apple’s approval:

“These apps would be just as secure as apps published on the App Store. I recommend that Gatekeeper iOS apps be subject to the same API restrictions, privacy permissions, and sandboxing as apps distributed on the iOS App Store”

Daniel and I discussed this on Core Intuition episode 207. We acknowledged that as great as it would be, this compromise of Gatekeeper apps being subject to API restrictions might not be possible. The whole point of Gatekeeper is to leave Apple out of the distribution process, so there would be no place to impose such restrictions except at the API level. Still, I’d welcome any kind of side-loading.

Most Mac developers have wanted a Gatekeeper-like solution for iOS since the very beginning of the iPhone. Back in 2011, I wrote a post about Apple’s 30% cut and the lack of side-loading for iOS:

“Apple’s tight control over iOS has always been troubling. If there’s no way to install an app on the device without Apple’s approval, then Apple can make or break any business that builds for the platform. It’s an added risk for the thousands of tiny development shops for which the iPhone and iPad are otherwise perfect.”

But side-loading isn’t really holding back the iPad. What’s holding it back is the slow pace of progress in UI improvements. For example, the home screen remains virtually unchanged since iOS 3, and on the iPad Pro the classic grid of large app icons looks more like the Simple Finder than a way to manage and launch productivity apps.

More key areas of the UI need to take inspiration from iPad multitasking. While split-view and slide-over aren’t perfect, they’re something. Likewise for iOS extensions, which were such a step forward that we were willing to overlook the UI clunkiness. These new features helped Fraser Speirs switch to an iPad Pro full time:

“The introduction of multitasking in iOS 9 has made a significant difference to the way I work on iOS. I don’t need to rehearse the actual features here but suffice to say that I now find iOS extremely easy to get almost any task done.”

I’d like to see Apple experiment more. To not be afraid to try something new with the UI and ship it, as long as they still follow up and refine it.

Here’s a great feature idea to take multitasking further, from Stephen Hackett’s iOS wishlist:

“I’d like Apple to work on some way to share text and images between apps that are side-by-side. If I’m working in a text editor, I’d like to send a selected portion right into Slack, without having to worry about a share extension or dropping back to copy and paste to get the job done.”

Nilay Patel, in a 2015 wrap-up for The Verge, wrote that Apple has been setting the groundwork for new platforms, and that this year they will have to iterate and improve on what they’ve started. He sees the iPad Pro in particular as a step forward without a clear defining feature:

“There’s a chance we’ll all be using huge iPads as our primary computers one day, but to get there the iPad Pro has to do something so much better than a MacBook that all the things it does worse seem irrelevant. What is that thing?”

That missing “thing” is clear to me: the Apple Pencil is the best stylus that has ever been made for a device — tablet, desktop, or standalone display. It’s so good that I assumed I would sell my retina iPad Mini and use the iPad Pro exclusively.

That hasn’t happened. I realized when making the choice of which iPad to take downtown the other week that the Mini is still my favorite size. I hope as part of the next phase to Apple’s iPad platform that the Pencil makes it down to the rest of the iPads. It’s important that developers can count on the common availability of the stylus, just as we can count on multitasking and app extensions to set the pace of UI progress for the platform.

Lightweight universal apps

When the iPad first shipped, many developers embraced completely separate apps for iPhone and iPad. The argument was that they were different platforms and deserved special design attention (and separate revenue). I never bought this argument, and eventually — with the iPhone 6 Plus and multiple screen sizes — everyone agreed that it just made more sense to use universal apps.

At the same time, there’s a parallel argument that an app on the iPad shouldn’t just be a “scaled up” version of the iPhone. That if you can’t invest the time to do a universal app properly, don’t bother.

The redesigned Twitter iOS app was a great example of this. It was widely mocked for it’s poor use of space on the iPad.

With the iPad Pro and widespread iPad multitasking, I think this changes again. An iPad app that is designed exactly the same as its iPhone version is still very useful in slide-over and split screen. In fact, for many “iPad” apps I use every day on the iPad Pro, I use them in their compact layout more often than full screen.

My next app was designed for the iPhone. I spent some time trying to rework it with split views for the iPad Pro, but I just can’t justify the work right now to finish that effort. I’m going to ship it as a “lightweight” universal app anyway, though, so that it’s available in slide-over. To me, that’s a worthwhile compromise, significantly better than no offering on the iPad at all.

Swift and Core Intuition 209

Like many developers, I’ve spent the morning looking over the Swift open source release. I continue to be intrigued and look forward to working Swift into more of my routine.

On today’s Core Intuition, Daniel and I talked about Swift for about half of the 50-minute episode. We recorded the episode yesterday afternoon, before the open source announcement, so we’ll be following up next week on everything that has changed. I bet there will be some more progress in Swift web server frameworks by then, too.

Apple Pencil, for real

As we talk about on Core Intuition episode 208, I finally got an Apple Pencil. It’s great. My experience matches Gus Mueller’s, about how good the Apple Pencil is after years of using Wacom tablets and third-party iOS styluses:

“I find that when using the HB Pencil in Procreate, I get something that is very, very close to what I feel when I’m drawing in my sketchbooks. But of course now I’ve got layers and many colors and a perfect eraser to work with. And endless pages. I love it.”

On the question of whether it’s a “stylus”, Ben Brooks sums it up this way:

“That’s the question I get asked a lot from people — my wife especially. Apple will tell you it is not a stylus because it is so much better than any other stylus, it clearly is something else. So, instead, I’ll tell you that it is very much a stylus — it just so happens to be the best stylus I have ever encountered on any device.”

I’ve also been improving the Apple Pencil support in an iPad app I’m working on. I haven’t completely finished reading Russ Bishop’s article on supporting the Apple Pencil, but looks like it has a bunch of additional tips in it that I’d benefit from. It covers not just the API changes to UITouch, but also gestures, coalescing, and predictive touches.

Developing for the iPad Pro

Let’s start with a quote from the MacStories review by Federico Viticci:

“For developers, it’s time to be bold with their iOS apps and understand that they can be more than single-purpose utilities. There are millions of people who aren’t buying PCs anymore because mobile devices are their only computers.”

I’ve been using the iPad Pro a lot in just the last two days. Apps that have taken advantage of the larger screen — and that support iPad multitasking well — are just much more useful. It’s great to have Slack or Tweetbot in the sidebar and a writing app in the main part of the screen. (Until Editorial is updated, like Seth Clifford I’ve switched to Byword.)

As a developer, going from an iPad Mini to an iPad Pro has opened my eyes to what Federico says above. You simply can’t have a great iPad app today if it doesn’t attempt to fit well on the iPad Pro. So although I said I would discontinue my app Tweet Library, I’ve actually been spending some time this week to update it to support iPad multitasking.

The key to iPad Pro support is actually less about auto layout (although that’s helpful too), and more about split views and size classes. For a modern app, this is an easy transition. But Tweet Library was written for iOS 4. Back then, UISplitViewController was extremely underpowered. I had used MGSplitViewController instead, which I’ve modified over the years to adapt to multiple screen sizes from the iPhone to the iPad. So the first step to real iPad multitasking was to rip out most of the split view code and start over with a clean foundation based on iOS 8/9 and UISplitViewController. Not exactly trivial work that I could knock out in a day, although I tried.

I remain very optimistic about the iPad Pro, especially when the Apple Pencil is actually available. From a business standpoint, it also seems like a better investment in time than either the Apple Watch or Apple TV. There are so many platforms and distractions now. If I can’t focus on a single platform, I want to at least be proactive in saving some attention for the iPad.

Two weeks notice: unfinished work

Three weeks ago I had about a dozen open Jira tickets. Today, my last day with the company, most of those are still open. I was able to update some documentation and do minor maintenance work, but a bigger change I had hoped to deploy turned out to be impossible because of a missing internal API.

It’s unsatisfying to leave unfinished work. There’s only so much that can be done in a limited time, though, and as we all know software (especially a web app) is rarely ever completely finished.

Bittersweet, moving on after so many years. The folks I’ve worked with have been really great. I’m going to enjoy keeping an eye on what they ship long after my GitHub access has been revoked.

This morning, my (now) former boss and good friend Willie Abrams linked in the company chat room to some of the photos that he had taken over the last 14 years. Brought back a lot of good memories, from brainstorming app features in a conference room to wandering around San Francisco before WWDC.

I think I’m going to let this be the final post to wrap up the “two weeks notice” series. I’ve accomplished a lot but there is still plenty left, especially shipping new products. It’s been good to force myself to write every day, so I’ll keep that going with the usual full posts and microblog posts.

You can find all 14 posts under the tag “2weeks”. Thanks for reading.

Two weeks notice: final pull request

With just 5 days left at my regular job, it’s time to get serious about wrapping up my work. I have a small change mostly ready and tested locally, but need to push it up to GitHub and finish testing on the dev server. I have a couple open Jira tickets to look at after that.

Over the weekend I spent a lot of time with the Stripe API, trying to improve how I manage user subscriptions. Stripe has some new features since I first started using it. For example, options for sales tax and a quantity field. The latter is convenient if you have something like the ability to pay for multiple hosted web sites in a subscription, rather than deal with adding custom line items on an invoice.

Deadlines are an excellent way to push yourself to actually finish something. So this deadline of Friday is good, in a way, but unlike most of my other deadlines, I can’t miss it and keep working for another week. That finality is a little daunting right now, as I look at the week ahead and everything I want to get done.

I think it’s a bust

The movie Draft Day doesn’t really have any business being good, but somehow it is anyway. I don’t even like football that much — who has time for it when there’s basketball? — but I’ve now seen this movie several times and love it. The movie actually gets better instead of worse on multiple viewings.

It also has a number of memorable lines. One of them is this, said by Kevin Costner’s character about the college football star who everyone thinks is the next greatest thing: “I think he’s a bust.” Five simple words that undo all momentum.

And unfortunately that’s still how I feel about Swift. I’m following Brent’s blog posts about learning Swift and I’m trying to come to terms with whether to adopt the language, and I finally got it. I already have a capable quarterback in Objective-C, and I’m not ready to rebuild my roster yet, risking everything on a young language with so much promise but less real-world success.

No matter how much Swift has improved, no matter how much everyone fawns over it, I still can’t shake the feeling that it’s a hype that someone else’s team needs. For me, it won’t end up solving the problems I have when building apps. For me, it’s a bust.

Retiring App.net support for Sunlit

Sunlit 1.3.1 shipped today. It’s a minor update focused on fixing bugs, but it is also the first version to remove App.net support. Existing users still have access to all the App.net features — the code still exists in the app for now — but the App.net sign-in button and settings have been removed for new users to simplify the requirements and UI.

It was difficult to let go of the App.net-specific features. A significant amount of the codebase was around syncing and collaboration features via App.net. There was also some great location check-in support built on App.net locations and compatibility with Ohai. I had to remove screenshots and prune down the App Store description to account for the removed features.

What’s left is an app that has fewer features but which feels light and simple again. Maybe this should have been our 1.0 version all along.

Two years ago, I wrote about waiting for App.net’s killer app:

“The promise of App.net is bigger than one type of app. App.net isn’t just a blank slate; it’s an amplifier. It’s waiting to power the next new idea and help it grow into something big.”

This vision didn’t pan out. But I’m proud that we gave it a shot and put a lot of effort into the platform even after others had given up on it. Now that we’ve finished this “reset”, of sorts, we’ll move forward to build other features we always wanted in Sunlit.