I wouldn't wait for "Marzipan" or XKit or whatever it is.
We don't know what it is. But my guess — based on my 38 years of writing code for Apple computers — is that it's something you can use along with UIKit and AppKit, and not a wholesale replacement.
Maybe it's a declarative API that helps make some things easier, and maybe you can make a cross-platform button more easily. Maybe your table view code could be the same on iOS and macOS. Great!
But don't expect Macs to turn into large iPads all of a sudden. Macs are gonna Mac. Apps are going to have multiple resizable windows and a menubar. Targets will still be sized and designed for mice and trackpads.
In other words, if you want to write a Mac app, you're still going to have to deal with the things that are inherently different about Mac apps, regardless of the specific API.
Let's say this thing ships in the fall of 2019, over a year from now. If past is a guide, we might imagine it would be fun to play with, but not more useful than, say, the original version of Swift. (Swift didn't get really good for writing apps until Swift 3.)
So it might be 2020 before it's something that accelerates Mac development in any real way.
You could write a few Mac apps between now and then.
* * *
I realize that documentation on writing Mac apps is hard to find these days. Books on the subject are rare, and any book you find may be out of date.
One of the reasons I made Evergreen open source is so that people who want to write a Mac app have some examples.
And I just learned that there's a big list of open source Mac apps. This is way more than than was available when I started writing apps for OS X.
I don't have time to write a book on Mac app development. I wish I did. I might make the time to do a small article now and then, using Evergreen as example. Maybe.
But it's not my job (as I have to keep reminding myself). It's Apple's job to document and evangelize the Mac platform.
(As an additional part of that, I'd like to see Apple update the Mac App Store, and maybe also deal with some of the issues with sandboxing. It would signal that the company cares about Mac apps. I know it does care, but a more public demonstration would be welcome.)
With the recent talk about Electron and "Marzipan" — or maybe Amber or something, according to Mark Gurman — I'm reminded of a thing I think about kind of often: that making iOS and macOS apps is way harder than it needs to be.
For most apps (except games, I suppose), a huge percentage of the code might as well be written in a scripting language. We absolutely do not need to be writing everything in Swift, Objective-C, C++, or C.
"But Brent," you say, "what about performance?"
Consider the case where you set up an animation and then run the animation. The system does that animation. Or consider Core Data — your choice of language doesn't affect how fast it can read from SQLite. Or think of networking — it's bound by the connection, not the speed of your code. Or think of pushing a view controller onto the current navigation view controller. Or setting up view constraints. And so on.
All this code might as well be Ruby — or, preferably, a scripting language designed for app making. (I would have liked an Objective-C-without-the-C.)
And the thing that would make it all so worthwhile is editing the code while the app is running. You could go all day without an explicit build step!
Sure, some of your code would still have to be written in Swift or whatever. The part that really does have to be fast. I'm a performance junkie myself, so I get this. (Evergreen's RSS parser is fast, and I wouldn't switch it to a scripting language.)
But most of most apps (again, probably besides games, about which I know nothing) could be written using a scripting language.
PS Yes, I'm quite aware that we used to have Fix & Continue. And WebScript.
Some of the press coverage about The Developers Union uses words like "angry" and "fed up." These aren't accurate characterizations at all. Nobody's mad here!
But here's the deal: Apple controls the App Store and its economics. The system could be set up better to support high-quality apps, by indies, that last for years.
Apple doesn't have to, of course. But we can ask! It's totally okay to ask, so we are.
We think that an important first step would be a standardized, App-Store-supported way of offering free trials. (And where, once purchased, Family Sharing works.)
Trial versions have worked great for years for indie Mac developers, before the App Store, and we think it would benefit indies on the iOS and Mac App Stores.
And the platform would get better — and more sustainable — apps. Everyone wins!
If you agree, you can sign up. Add your name. Add your app.
I realize you might be worried about doing a thing that could upset powerful people inside Apple. I strongly doubt that that worry is actually well-founded — but, then again, that's part of why this is a big list.
* * *
I should note that I'm not doing this as part of Omni. I'm not even doing it for my side projects — they're all free, and it's quite possible that none of them will ever appear on any App Store at all.
Instead, I'm thinking of my friends, of developers I admire, of up-and-coming developers I haven't even heard of yet. I — quite selfishly! — want them to thrive. I want to see what great stuff they could make. I want everybody to have the opportunity I've had.
I've been lucky, and I've done well — and my experience should not be rare.
Lately I've been trying to learn to play delta blues. I'm not ever going to play like Robert Johnson — nobody ever will — but I'd like to learn it as well as I can. Well enough so that, if you like the blues, and you heard me at a coffee shop, you'd enjoy it.
(Not that I'm going to start playing at coffee shops.)
I've been playing guitar for 38 years, and I've known the 12-bar blues progression and the blues scale for almost as long. But I always figured that learning to play like this would be way beyond my abilities.
* * *
The first thing to notice is that, in the hands of someone like Robert Johnson, it sounds like two guitars playing.
Roughly speaking: the thumb is doing a regular shuffle beat, often with two strings, while the other fingers are doing fills and melodies. At the same damn time.
I'm a life-long strummer and power-chord player. Flat pick. Rhythm guitarist. I've never had to develop this kind of coordination. It's difficult.
The second thing to notice is that every single pitch your guitar can make is on the table. Sure, there's a progression and a scale — but players regularly use notes outside the standard blues scale, and they hit pitches, by bending strings, that are between the notes.
And throw a slide in — which I'm learning to do — and it's just nuts.
This music is incredibly complicated compared to the pop rock I've always played.
* * *
But I am learning it. Slowly. It's going to take a few years before it sounds effortless. Right now I sound like a person trying really hard.
The thing is this, though, and this has wider application: for some reason, when I was a teenager, I told myself that I didn't have the talent to play anything more complex than basic rhythm guitar.
I learned the cowboy chords, barre chords, power chords, notes in first position — and convinced myself I didn't have the ability to learn fingerpicking or delta blues or anything that would make me a musician as opposed to just someone with a relaxing hobby.
I honestly don't know why I thought that! I mean, I learned all this stuff, and figured I couldn't keep learning at some point?
But here I am, now, learning it. It's hard, but I'm learning.
* * *
Maybe I was confused by the word "talent." I didn't think I had that thing — where is it? I can't see it — and I figured that, without it, I had hit my wall.
But... I've always been good at rhythm. It comes so easy that I thought everybody had that ability. And then I've seen other guitarists struggle at rhythm bits that take me no time to learn.
I'm also very good at remembering songs. It's like I have a karaoke machine in my head. This comes with little effort at all — once I learn a song (sometimes just by hearing it) then, usually, I know it forever.
At least the chords. At least enough to be able to play it by the campfire. (Or at a piano, because that's a thing I do too. Though I play piano like a rhythm guitarist. :)
Maybe these are some small musical talents that I actually do have?
But: hearing pitches and intervals and understanding melody is much harder for me, and that's just come with a ton of practice. Mostly by listening, trying to recreate what I hear, and trying to figure out why it works.
* * *
I think I'm making a point about impostor syndrome. I told myself I couldn't learn to play guitar at a deeper level — at the level of real musicians — and here I am at age 50 wondering why I told myself that, because here I am doing it.
Why did I wait so long?
And, sure, maybe I do have some small amount of musical talent, but whatever. If I hadn't, I probably wouldn't have been interested at all.
So maybe it's a good bet that if you're interesting in a thing, you may already have some talent for it. And maybe, just maybe, interest and talent are really synonyms, or close to it.
* * *
PS I started playing with a thumbpick to get that bass shuffle sounding good.
In this episode we talk with Dave Lonning, who writes documentation for Omni apps. Dave's a long-time fan of role-playing games — running them and creating them — and he lived for years in Japan before making his way to Omni.
Among Dave's hobbies is painting miniatures:
Dave, it should be noted, is a cat person — but, importantly, he's learned to love the Omni dogs. They're good dogs, Dove.
I realized that I want my blog to be me on the web. This used to be true, but then along came Twitter, and then my presence got split up between two places.
To make this work, I needed two things that my old system from 2009 didn't provide:
In other words, I needed to be able to write tweet-like posts with no title — while on the go, on my iPhone or iPad.
I've done #1 and part of #2 — now it's just a matter of figuring out how to deploy the system to my server (which is a shared host on Dreamhost, but where I can run CGI scripts).
The code's up on GitHub. I don't really expect other people to use it, but you can, if you want to. I apologize in advance for not having time to write extensive documentation or provide support.
The system's pretty fast: it rebuilds this almost 20-year-old blog in about three seconds on a five-year-old iMac. The code is, I hope, understandable and hackable, and I welcome you to fork it if it interests you.
* * *
Another part of this: I'll stop using micro.inessential.com. This blog will be my blog and my microblog. I want just one place that's me.
I don't know if I'll have my posts here automatically echoed to my Twitter account. Maybe. They do already appear on Micro.blog.
PS Titles were always optional for RSS, but most feed readers don't handle this well. Evergreen was written with this in mind. (It's not 1.0 yet, though. Working on it!)
I wrote last February on why Micro.blog is not another App.net.
Though that article had a bunch of good reasons to use Micro.blog, I didn't really say why I use it.
This vile season, run by crime families, shot through with bad faith and giddy injustice, with the highest frauds and the lowest characters, has me looking everywhere for the exit.
But there is no exit. There are only choices: each of us can choose to do things, usually small, that will help make things better.
We could continue to flock to Twitter and Facebook — we could keep paying those who have and will rip off democracy for a stock price — or we could turn our backs and help the open web instead.
We could say goodbye to the creepy targeted ads and the algorithms, to the Nazis and bots and propagandists, to the harassers and the people selling hate. We could stop being spied-on for profit.
But only if we make the choice, and then work at it.
We could dine out forever on our knowing that it was all doomed — that we were too smart to try, too wise to risk even the smallest lift. We knew it all along.
Or we can make the moral choice of renewal, of planting new bulbs and helping this old tree, a little bigger now, flower again.
Our hearts may end up broken. Again.
I'm quite aware that my recent blog posts without titles look weird in some RSS readers.
Here's the thing, though: the RSS
title attribute was always optional. It's just that RSS readers were written with the expectation that it was mandatory.
If you write an RSS reader with a timeline and detail view, here's what you could do:
descriptionin the timeline, after stripping HTML.
If you want to see an example, subscribe to this blog in Evergreen. Sure, it's not 1.0 (or even beta) yet, but it handles title-less posts the way I've described above.
Here's why this is important:
We're already seeing more and more microblogs, and we're seeing blogs like this one that have some long posts and some microblog posts. (When you see the word "microblog," think tweet-like, but with HTML.)
This is an important part of the future of blogging. It's the movement away from posting to Twitter first — instead, you post to your blog (or microblog) and then, optionally, echo the post to Twitter.
Things have slowed down for Evergreen — but only temporarily.
I had to spend some time turning 50 years old, which was ridiculously good fun. (One day I hope my 11-year-old nephew and I finish the cover of "Smells Like Teen Spirit" we were working on!)
And... my nine-year-old blogging system needed an update, and I just couldn't stand it anymore, so I rewrote it. It's nearly finished now — finished enough that I can post to my blog again, at least.
And then I realized that I had kind of a mess with Evergreen and Frontier frameworks. I was thinking about how I wanted Frontier's hierarchical key-value database (which I haven't written yet) in Evergreen — and so, obviously, they should share this framework. And, well, there are a bunch of frameworks they should share.
So I started work on converting over to Git submodules, so that they can share frameworks, and so the frameworks can live in their own separate repositories. Which of course also meant learning how Git submodules work in the first place.
And it turns out that Frontier doesn't build right now, and needs to be updated for Swift 4. But it needs to build before I can tell if I've got frameworks-as-submodules set up there correctly.
Anyway — long story short — there's finishing the blogging system and then doing a bunch of housekeeping stuff.
In other words: it's infrastructure week! (And will be for a few more weeks, I expect.)
And then I'll be back to Evergreen. It should be just one more push of a few months to get it to 1.0.
Steven Aquino, in Giving Tweetbot a More Accessible Design, writes that Twitter's official client for iOS does a good job with accessibility:
The UI design is much higher contrast — Twitter for iOS even acknowledges when you have the system's Increase Contrast setting enabled, as I do. And, crucially, the official client natively supports alt-text, which allows users to append image descriptions for the blind and low vision before tweeting.
A line in Frank Chimero's article Everything Easy Is Hard Again, published a couple months ago, has stuck with me:
That breaks my heart, because so much of my start on the web came from being able to see and easily make sense of any site I'd visit. I had view source, but each year that goes by, it becomes less and less helpful as a way to investigate other people's work.
One of the ironies of this is that HTML5 makes it easier than ever to make readable, simple HTML. I especially like two things:
article, and similar now.
So I adopted the semantic HTML5 tags, simplified a few things, and now the source is as easy to read as any HTML I've ever written.
Lesson learned: the discoverable and understandable web is still do-able — it's there waiting to be discovered. It just needs some commitment from the people who make websites.
Jason Kottke reminds us that blogging is most certainly not dead, and that there are great blogs out there.
My only objection is the use of the word "dead" to apply to things that aren't alive. Even when you're saying that something is not dead.
I've done it myself. It's shorthand, yes, but it's a broad binary take when something more nuanced and true would be warranted.
On the blues harp:
A diatonic harmonica is designed to ease playing in one diatonic scale...
Blues harp subverts the intention of this design with what is "perhaps the most striking example in all music of a thoroughly idiomatic technique that flatly contradicts everything that the instrument was designed for."
What I'd rather do: run that little web server on the actual server, and do the static-site generation there. That way I can post from my iPhone and iPad, not just from my Mac.
But... here's where web deployment gets tricky. I'm on an inexpensive shared host plan at DreamHost. The machine is running an older version of Ruby that's incompatible with my scripts.
That is, if I could figure out how to use this stuff and get it installed on the server. Looks like something I could spend weeks doing (remember that my hobby coding is limited to nights and weekends).
Alternately, I could get an inexpensive VPS from one of the various providers and set things up there. That might be easier — maybe I could skip RVM and Bundler and just install the things I want to use in the old-fashioned way.
But then I have to deal with a bunch of other things myself, including setting up Apache or Nginx. All the things DreamHost does for me automatically I'll have to handle myself. That doesn't sound like fun at all.
I totally don't know what to do. It's not my plan to become a Ruby deployment expert or to be on the hook for running a server all the time. I've done way too much of that kind of thing for one lifetime already, and I've mostly been glad to be out of it.
What surprises me is that in 2018 it still requires so much work just to get a CGI script running on a server. It should be easier.
There's an unofficial Seattle Xcoders this Thursday at the Cyclops in Belltown. I plan to get there around 6 pm.
We're always in back, next to the bar but technically in the restaurant section. Anyone is welcome — you don't have to be a coder! We regularly have designers, testers, support people, product managers, and so on.
Heck, even if you're a fan, you should come. Should be a beautiful night to hang out with some fine folks.
The latest episode of The Omni Show is a special episode — we talk about OmniFocus 3 and flexible inspectors, enhanced repeating tasks, batch editing, and the interleaved Forecast view.
Regular interview shows are our bread and butter, but these roundtables are fun to do too. (And I can't wait for The Omni Show Live next door to WWDC!)
Say you write an iOS app, and now you want to write the Mac version.
Assuming there's a data model, maybe a database, some networking code, that kind of thing, then you can use that exact same code in your Mac app, quite likely without any changes whatsoever.
That leaves the 20% or whatever that's user interface. AppKit is not the same as UIKit, but it's recognizable. Same patterns and concepts, and often similar names (UITableView/NSTableView).
Given that you've done the hard thing — learning UIKit, Xcode, and Swift and/or Objective-C — taking the next step and learning AppKit seems like a very small thing. You've climbed the mountain already, after all.
You might complain that AppKit has some weird stuff. True. Some of it, though, isn't truly weird — it's just weird to you if you've never dealt with things like a menubar and multiple, live-resizable windows.
People coming from AppKit to UIKit (few people these days; many people 10 years ago) might also complain about safe content area insets (or whatever the thing is these days) and size classes and all manner of strange stuff they like not having to deal with in Mac apps. UIKit's weird too, to some people.
Ten years ago I thought that all the new iOS developers would translate to lots more Mac developers. That that didn't happen is a huge surprise to me. Because if you're an iOS developer you're practically a Mac developer already.
(And — little-known secret — the economics of Mac apps appear to be more favorable than for iOS apps.)
It's not finished yet — it doesn't even build.
It's hierarchical key-value storage. No schemas. Tables can contain tables, with no limit.
This implementation is the lowest level: the part that gets, sets, and deletes data from the database.
It's application-agnostic, at this level — it doesn't know about all of Frontier's data types, for instance. A level on top of this will be needed for new-Frontier.
I'm not actually writing a new database — I'm using SQLite. And that's because I've been using SQLite for 15 years, and I love it and know it well, and I know how incredibly stable it is. I'm not willing to write my own thing, and I'm not willing to use a thing less mature and rock-solid than SQLite.
How it works:
The schema is pretty simple. There are tables and values.
Every table has an
id. Every table (except the root table) has a
parent_id that points to its parent table.
And every value has an
odb_table_id that points to its parent table.
This way it's easy to get a table's children: it takes just two
(Both tables and values also have a
name, since this is key-value storage.)
Tables and values will be cached in memory, so not every call will require a database read.
(Before you suggest I use something other than SQLite, know that I won't change my mind on this.)
(Also, again: it's not done yet. Doesn't even build.)
I'm using schema-less storage for feeds in Evergreen. (Articles and article status, on the other hand, are stored using a schema, in SQLite.)
Currently I'm writing a big binary plist with all the feed data, and it has to be rewritten every time a feed property changes. The writes are coalesced — but still, this isn't great.
I'm using schema-less storage in part because of syncing systems: I don't know, and can't guess, what I'll need to store. Different systems will have different requirements.
Also: I may add features later that require additional feed properties. I don't know what those are.
I realized that what I really want for this is a feature from Frontier: hierarchical key-value storage.
Each system will gets its own database on the client. For each, I'll create an odb table called
feeds. Each feed will have its own subtable. The key will be its id (which may or may not be its URL, depending on the syncing system).
And inside each subtable I can put whatever I want, at any time, without having to change any schemas or implementations.
For the On My Mac account — not synced; reads feeds directly — we keep track of Etag headers in order to support conditional GET. So, for example, I'd want to get, set, and delete
But with most syncing systems we get the feed content from the system itself — not by directly reading the feed. There might be some other data from the service to store:
feeds.[feedID].syncToken, for instance.