Category Archives: Programming

Micro.blog themes open source

Micro.blog launched with 6 unique themes, and advanced CSS support to customize many aspects of the design. I love seeing users take one of the existing themes and make it their own, such as what Dan Counsell has done with colors and fonts on his site.

The publishing engine for Micro.blog is based on Jekyll, so of course the themes are Jekyll themes as well. I wrote last year about why I chose Jekyll. I’ve forked several themes to improve their support for microblogs, JSON Feed, and IndieWeb standards.

A few of these changes are now up on GitHub. You can find these themes in the @microdotblog repository:

I’ll be updating the other themes on GitHub soon. While you can’t upload an entirely new theme to your Micro.blog account yet, many people have asked for that, and hopefully these themes will provide a starting point.

Micro.blog post titles demo

Last week I wrote about Micro.blog for iOS version 1.1, which adds several new features including support for multiple photos and longer posts. Today I want to demo how longer posts work on the web version of Micro.blog. Here’s another quick screencast with audio:

Micro.blog iOS 1.1

Micro.blog for iOS version 1.1 is now available. This release adds a number of new features:

Added support for longer posts with titles. Type more than 280 characters to reveal an optional title field.
Added Markdown syntax highlighting while typing.
Added formatting bar for common styles. Select a phrase and tap the link button for easier markup.
Added support for uploading multiple photos.
Added a Browser sharing item to open the current post on the web.
Fixed a potential crash in profile links and glitch when holding down to select text.

Here’s a quick screencast showing some of the highlighting and title support:

Hope you like the update. You can download it from the App Store

Micro.blog iOS going universal

As I expected would happen, using iOS 11 on my iPad Pro after WWDC has inspired me to revisit the universal version of Micro.blog for iOS. Here’s a screenshot of my current build:

Micro.blog iPad

I plan to include this in 1.0. I’m in the process of moving the app from TestFlight to its final home in the App Store. As we prepare for the public launch, this’ll make it much easier for everyone to download it, and it shouldn’t be limited or scaled up on the iPad.

Siri’s slow pace

It’s WWDC week. I’m back home after a short week in San Jose. Monday’s keynote was a big event, with great news for Mac and iPad users, but I keep coming back to the most surprising “miss” in all of the announcements, and the one thing that I thought was surely a lock for the conference: SiriKit.

When I was on The Talk Show last week with Brent Simmons, John Gruber wrapped up the episode by asking about expectations for WWDC. I’m a big fan of the Amazon Echo, and I think Siri is behind in responsiveness and extensibility. I predicted at least 20 new domains and intents for SiriKit, if not a more open architecture that could grow into as big a platform as Alexa’s thousands of skills.

This week should’ve been a great one for Siri. Instead, we got not the hoped for 20 new domains but literally only 2, for taking notes and managing to-do lists. HomePod will have no support for apps at all, and it will initially ship only into a few English-speaking countries, erasing the traditional advantage Siri had over Alexa for localization.

There are good ideas in SiriKit. I’m excited about experimenting with creating “notes” in my app, and I like that in session 214 and session 228 they highlighted some of the new tweaks such as alternative app names and vocabulary. But there has to be more. Siri deserves several sessions at WWDC and much more attention from Apple.

Voice assistants represent the first real change in years to how we interact with computers, perhaps as important as the original graphical user interface. The company that created the Knowledge Navigator concept video should be firmly in the lead today. A year from now, at WWDC 2018, the lack of significant improvements to Siri will have stretched to 2 years, and that delay is going to look like a mistake even to Siri’s most vocal defenders.

First week of JSON Feed

I’ve been impressed with how quickly people have adopted JSON Feed. There are a bunch of feeds in the wild now, as well as code and templates for popular languages and web frameworks. The next step is support in feed readers, including brand new feed readers, which is already happening.

Feedbin and NewsBlur both added support for JSON Feed. I like how Feedbin’s Ben Ubois puts it:

One of the criticisms I’ve seen of JSON Feed is that there’s no incentive for feed readers to support JSON Feed. This is not true. One of the largest-by-volume support questions I get is along the lines of “Why does this random feed not work?” And, 95% of the time, it’s because the feed is broken in some subtle way. JSON Feed will help alleviate these problems, because it’s easier to get right.

Micro.blog can also read from JSON feeds. I’ll be switching over all the hosted sites to prefer JSON. I’m doing that slowly to make sure there aren’t any issues with duplicate posts. (There shouldn’t be, but it’s something to watch out for with self-hosted sites if your post IDs change.)

The WordPress plugin is almost in the WordPress directory. I’ll link to it as soon as it’s live, because it will make installing the WordPress plugin much easier.

JSON Feed

Really excited to announce JSON Feed today with Brent Simmons. It’s great to see all the feedback and links to new feeds. Special thanks to everyone who contributed to the spec, debating field names and requirements over the last few months.

The premise was simple: the time is right for a JSON-based approach to feeds. We hope that JSON Feed is straightforward enough to be implemented quickly, and capable enough to push the next decade of blogging software forward. We love RSS too and tried to learn from its success.

Micro.blog already supports JSON Feed nearly everywhere. There are feeds for hosted microblogs and your timeline, and the Micro.blog custom JSON API itself is actually just JSON Feed with Micro.blog-specific extensions.

I’m looking forward to seeing what everyone does with this. If you’ve shared any code or templates for JSON Feed, or if you’re working on apps to support it, let us know.

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.