The Liscio Approach to Variants in Swift

In two recent posts — see how we keep calm and carry on? We’re back to tech topics — I wrote about implementing variants in Swift 2.0.

(See Swift question: Enum vs. Struct for Variants and, before that one, Swift Protocols Question.)

In both cases I was definitely thinking like an Objective-C programmer — I was thinking about how to wrap native types in a variant type.

One approach was to use an enum with associated types, which is much like using tagged unions in C. Another approach was to create a different struct for each under-the-hood value type and have them all conform to a Value protocol.

Chris LiscioCapo author (Capo is genius, FYI) — suggested another approach: Don’t wrap. Don’t box. Just use the native types directly.

That is, instead of creating something like this…

protocol Value {
  func valueBySmashingOtherValue​(value: Value) -> Value
}

BoolValue : Value {
  let value: Bool
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

IntValue : Value {
  let value: Int
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

etc.

…do this instead:

protocol Value {
  func valueBySmashingOtherValue​(value: Value) -> Value
}

extension Bool : Value {
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

extension Int : Value {
  func valueBySmashingOtherValue​(value: Value) -> Value {
    // do something and return a Value
  }
}

etc.

That is, extend the native types instead of wrapping them.

In Objective-C you can’t extend BOOL or NSInteger since they’re not object types, but in Swift you can extend Bool and Int and similar types.

At my stage in learning Swift I wouldn’t have thought of this — but Chris did. (Thanks, Chris!)

(The advantages of this approach are, I hope, self-evident.)

PS The code above hasn’t been checked to see if it compiles. (Written directly in MarsEdit.) But you get the idea.

PPS I am frequently tempted to write that Objective-C is my lightsaber. But I don’t think that’s fair. I think it’s more that I’m still learning how Swift can be elegant — and Chris’s approach here counts as an instance of elegance.

Curtis Love

Curtis Herbert, Tough Love:

Instead of looking inwards at a lack of success I think we would be better served looking outside our community. If we look externally we’ll see that the App Store isn’t full of doom-and-gloom bad for indies, but rather markets at large are stacked against indies.

Absolutely right.

I’d add, though, that each market has a shape, and the shape of the iOS App Store is in Apple’s control. They can’t control the behavior of people, but the shape of the market has an impact.

I’d also add that a high volume of high-quality, interesting apps is good for selling iPhones and iPads.

Are there things Apple could do that would make the iOS App Store better for indies, so that we’re not rejecting iOS app ideas out-of-hand? I think so. There’s no silver bullet, but there are numerous good ideas that, taken together, could make a significant difference.

It’s still going to be tough for indies — there’s no way out of having to design well, work hard, and market effectively, and we wouldn’t want a way out; we like it tough — but every inch of lowered risk and every dollar of greater reward makes a difference.

So Much Love

Allen Pike, The Supply-side Blues:

However, when expressing frustration with the current economics of the App Store, we need to consider the effect of this mass supply of enthusiastic, creative developers. As it gets ever easier to write apps, and we’re more able to express our creativity by building apps, the market suffers more from the economic problems of other creative fields.

Love

At the Cyclops the other night I was talking with fellow Mac and iOS developers. One person mentioned that a friend had acquired an iOS game — a good game that’s less popular than it deserves, that maybe just needs some marketing.

Person: “So here’s the question. Would my friend’s iOS app be successful if…”

Everyone else at the table: “No!”

We didn’t wait for the “if” clause, because there’s nothing that could be in it that would matter.

That’s not to say that there aren’t successful iOS apps. Of course there are. I know people who work on them. I work with people who work on them.

But the odds are so very long.

Do we still talk about new apps and recommend apps to people? Hardly, these days.

* * *

Well, that’s freaking dark, and I guess I did say it out loud. Hello despair:

…there’s nothing that could be in it that would matter.

Okay. I feel responsible for letting you out of this post a bit more nicely. Despair isn’t my style.

* * *

If I estimate the number of iOS apps in the App Store, and get the difference between the estimate and the actual number, that difference will be larger than the number of successful apps.

(I define successful as a good-faith “makes enough of a profit to make it worth continuing to work on the app.” Most apps fail to make a profit at all, of course.)

I haven’t done an actual study. But do any developers doubt that I’m right? And when developers think this way, they take their app ideas and toss ’em aside.

“Hey, you know what, this idea would be really great for iPad! Darn.”

“This would be perfect for iPhone! Oh well.”

Shrug. Whatareyagonnado?

* * *

Yes, there are strategies for making a living, and nobody’s entitled to anything. But it’s also true that the economics of a thing may be generally favorable or generally unfavorable — and the iOS App Store is, to understate the case, generally unfavorable. Indies don’t have a fighting chance.

The platform is awesome. We love writing iOS apps. It’s fun and massively rewarding in every way except monetarily. As a craft — as a budding art form, perhaps — it’s juicy.

* * *

You might think that development needs to get easier in order to make writing apps economically viable. The problem is that we’ve seen what happens when development gets easier — we get a million apps on the iOS App Store. The easier development gets, the more apps we see.

And, the easier development gets, the more is expected of the apps you write, and the less people will pay. You probably have to do syncing. You need a companion Apple Watch app. And so on.

I kind of want to say that development needs to get harder — but what I really mean is that we need to solve harder problems in our app. Think of the difficulty level in things like Capo — do something actually very difficult like that, create a great UI and market the app well, and you may have a success.

The problem, of course, is that you’re taking a big risk. Your odds may be better when you’re solving a truly difficult problem — but the investment in time is bigger.

And that’s not a general solution to the economic problems of developing iOS apps.

I don’t have one. Maybe there isn’t one.

(Well, there’s Mac apps. Want a business? Write Mac apps. But that’s a closely-guarded secret, and I promised not to tell anyone. You didn’t hear it from me.)

* * *

This is the age of writing iOS apps for love.

Well, that’s not true for everybody. Well-established and awesome companies such as Omni, Panic, Flexibits, AgileBits, Tapbots, and The Iconfactory have a business writing iOS apps. (They do it for love, but not just for love.) Companies like Black Pixel make money by writing apps for other companies that have money.

And big companies and funded companies don’t actually have to make money from their iOS apps. They have other goals. (I don’t pretend to understand the economics of funded companies.)

You the indie developer could become the next Flexibits. Could. But almost certainly not. Okay — not.

What’s more likely is that you’ll find yourself working on a Mobile Experience for a Big National Brand(tm) and doing the apps you want to write in your spare time.

If there’s a way out of despair, it’s in changing our expectations.

Write the apps you want to write in your free time and out of love for the platform and for those specific apps. Take risks. Make those apps interesting and different. Don’t play it safe. If you’re not expecting money, you have nothing to lose.

Could the do-it-for-love era — with the creative freedom that that brings — bring us back to the days when we downloaded apps that weren’t from Facebook and Starbucks and Funded Company X, and we told our friends about our exciting finds?

I hope. I have hope.

Swift question: Enum vs. Struct for Variants

In a previous post I mentioned using structs plus a protocol to implement a variant type. There’s a Value protocol and a number of different structs that conform to that protocol.

But Andy Matuschak’s comment about using an enum instead keeps coming to mind. And then there’s this note in the pre-release Swift book:

Alternatively, enumeration members can specify associated values of any type to be stored along with each different member value, much as unions or variants do in other languages.

So let’s imagine a variant that can represent a bunch of different data types and that has logic for arithmetic operations and for coercions.

enum Value {
  case variantBool(Bool)
  case variantInt(Int)
  case variantString(String)
  etc. — for doubles, dates, data, collections, and so on
}

(Forgive the “variant” prefix in this example — it’s there so I’m not writing case Bool(Bool) and so on.)

Now let’s say we have a bunch of logic.

func canAddValue(value: Value) -> Bool
func valueByAddingValue​(value: Value) -> Value

And so on for subtracting, multiplying, and dividing. (Example: variantStrings can add and subtract other variantStrings and things that can be coerced to variantStrings, but they can’t multiply or divide. variantData can’t do any arithmetic at all. Etc.)

And then add logic for coercions:

func canCoerceToType​(type: Value) -> Bool
func valueByCoercingToType​(type: Value) -> Value

(This is a little weird because a Value is a type — variantBool, variantInt, etc. — as well as data.)

There’s a whole ton of logic there: a variantDate can be coerced to a variantDouble but not to a variantArray, etc.

Unless I’m missing something — which is highly likely, as I’m just barely starting — I’ve got a whole ton of switch statement to write. And those switch statements have inner switch statements. (Conceptually, that is. Of course I would break things out into separate functions, as in func variantBool​CanCoerceToType​(type: Value) -> Bool and so on.)

That seems a lot to me like writing C code with tagged unions. Which is not necessarily a bad thing — I grew up on C and and still love programming in C (though I don’t get much chance to do it these days).

My original idea — a Value protocol plus a bunch of structs conforming to Value, one for each type — is something an Objective-C developer who’s new to Swift would come up with.

I realize it’s still early to ask about idiomatic Swift and best practices, but I’m asking anyway. What would you do?

Varieties of News Readers

I think — provisionally — that there are three types of news readers. (Am I missing any?)

1. Casual Newspaper

This category includes Flipboard, Zite (sadly defunct), the upcoming Apple News, and others. These tend to have the richest user interfaces of all news readers, with lots of pictures, animations, and interesting layouts.

Typically you pick some categories that interest you and perhaps some sites. You may also add RSS feeds and you might have it pull links from your Twitter and Facebook feeds.

These tend to have significant server backends that not only read various feeds and sites but also assemble (via algorithms and curation) a set of articles personalized for each user.

These are casual because, as with an actual newspaper, there’s no expectation that you’ll read everything. These tend not to have unread counts, for instance.

2. Productivity App

This category includes apps like Reeder, NetNewsWire, Google Reader (now gone), Feedly, Fever, and others. Their user interface often resembles a Usenet reader or email app. These apps often have things like unread counts and power-user features such as extensive keyboard shortcuts.

These tend to be RSS readers specifically, though not necessarily entirely so.

They don’t always do anything about relevance or personalization — personalization is entirely in the hands of the user, who picks which feeds to read. Some do include relevance features, but in general these apps are for people who want the control in their own hands, who don’t trust algorithms or curators, who don’t want to miss something that might be important.

There are two subcategories of productivity apps: browser-based server apps and native apps. Interestingly, the native apps often provide syncing by connecting to a server app (which may be made by a developer who’s not the same as the native-app developer).

3. River of News

These are reverse-chronological streams with optional titles and a short amount of text — often just a summary or excerpt of the linked-to story. (See Dave Winer on What is a River of News aggregator?)

These are also somewhat casual in that there are generally no unread counts and there’s no pressure to read everything. You read by scrolling, and you scroll as far as you want to.

There are two subcategories: RSS (or RSS mostly) and social network feeds. Twitter and Facebook could both be considered news rivers. (The RSS variety came first by many years, of course.)

Rivers sometimes have relevance algorithms behind them — as with Facebook, for instance — and sometimes not. They may be stand-alone, without any form of syncing, or they might have giant server back-ends — or something in between.

Swift Protocols Question

I’m still very much a Swift newbie.

The following example is contrived, but it accurately depicts the problem I’m trying to solve.

I have a protocol:

protocol Value: Equatable

A number of different structs conform to this protocol. Some of those structs also conform to this protocol:

protocol Smashable {
  func valueBySmashing​OtherValue​(value: Value) -> Value
}

My intent is absolutely clear — valueBySmashingOtherValue must return an object that conforms to the Value protocol.

However, I get this error: Protocol 'Value' can only be used as a generic constraint because it has Self or associated type requirements.

Okay. So I revise the Smashable protocol like this:

protocol Smashable {
  func valueBySmashing​OtherValue​<T>(value: T) -> T
}

That compiles. Cool.

So in a struct named Foo I add this:

func valueBySmashing​OtherValue​<T>(value: T) -> T {
  return Bar()
}

That’s right — Foo’s ​valueBy​Smashing​OtherValue returns a Bar. (Yes, this is contrived, but it distills the more-complex real-world code, which makes sense and is absolutely the right thing to do.)

Both conform to Value.

But I get this error on the return Bar() line: 'Bar' is not convertible to 'T'.

At this point I don’t know what to do. Hence this blog post.

Objective-C version

I approach Swift exactly like an Objective-C coder — because I’ve been writing Objective-C for almost 15 years. Here’s the Objective-C version:

@protocol Value<NSObject>
stuff
@end

@protocol Smashable<NSObject>
- (id<Value>)valueBy​SmashingOtherValue:​(id<Value>)​otherValue;
@end

Foo method (Foo and Bar both conform to Value):

- (id<Value>)valueBy​SmashingOtherValue:​(id<Value>)​otherValue {
  return [[Bar alloc] init];
}

One possibility

I’m still thinking in Objective-C. It’s entirely likely that there’s a Swift-like design that hasn’t occurred to me. But what is it?

One simple possibility: don’t use protocols at all. Make a Value struct that does everything the various Value-conforming structs currently do. The Value struct would be littered with switch statements, which is ugly (and is usually a sign of poor design), but it would work.

This doesn’t seem Swift-like, though, given the importance of protocols to Swift. And I can’t make myself do it.

There must be a better option.

What I don’t want to do is complain, a la Nabokov, that this new language can’t match the suppleness of my native language. I’d rather assume it’s just that I haven’t learned this new language well enough.

P.S. I’ll happily link to your blog post if you write up a solution.

Update 10:30 am Monday June 22:

Answers

There are a bunch of replies on Twitter.

The essence of the best answers was this: Value should not be Equatable — the individual structs should be Equatable.

Brent Royal-Gordon:

Thinking more, the problem is Equatable. Remove or abstract that conformance from Value and everything will work right.

For more details, see David Owens II’s blog post:

…there is a way out of this if your situation allows for it: don’t conform your protocol to Equatable, instead, conform your types to it.

And Llamagraphics’s blog post:

The error message says Protocol ‘Value’ can only be used as a generic constraint because it has Self or associated type requirements. This is a little misleading, because it implies that valueBySmashingOtherValue needs to be rewritten as a generic function, but that actually just pushes the problem down to the adopters of the Value protocol. The real fix is to move the use of the Equatable protocol from the Value protocol to the individual struct declarations…

And see Andy Matuschak’s gist — which makes an interesting point that I had briefly considered and then dropped:

One note before we start: if the inhabitants of Value are a closed set, then making Value an enum is going to be a clearer model than using a protocol like this. I'm assuming you need to be able to retroactively add new members of Value.

In my case, the inhabitants of Value are a closed set. There are about a dozen.

What concerned me, though, is that I’d be creating a monster enum with a whole bunch of switch statements. But perhaps that’s not true? I don’t know Swift well enough to think it out in advance — I’d have to try it and see.

(Actually, I may be misunderstanding Andy. There are a dozen Value types — but the values are unbounded. Perhaps not a great case for an enum.)

Ramble

In the end, I’m still tempted to say the Objective-C version was simpler. And it is, and not just because I’m more familiar with Objective-C. But it’s important to note that it’s not apples-to-apples. In Objective-C I’m creating classes instead of structs, and there’s no support for the == operator.

But I will say this: Objective-C, because it’s less strict with types, is closer to a scripting language than Swift is.

I know that that could be controversial, and seems absurd when you consider that Objective-C is a superset of C, which is pretty darn far from a scripting language. But Objective-C as-we-mostly-write-it doesn’t include much straight C code.

That’s not a value judgment but a characterization. There is a place for strict, less-strict, and not-strict-at-all languages — they all have their uses.

But when I imagined Apple’s next-generation language, I imagined a higher-level and less strict language — one that made it easier to get started as a developer, one that got rid of a bunch of the housekeeping we have to do as Objective-C developers.

Though Swift does get rid of a bunch of housekeeping — we can use type inference much of the time, we don’t have to create .h files, etc. — it adds its own housekeeping mandated by a stricter type system (and optionals).

When I think about how much of our apps is user interface code — which is often rather boring to write and is just stuff like setting a label, animating a property, pushing a view controller, and so on — I wonder why we’re not using an actual scripting language. It wouldn’t have to be for all of a given app — not for the performance-sensitive parts — but it would be great for all the stuff that’s just pushing user interface APIs around.

More About http Deprecation

Dave Winer writes about http deprecation in The People’s Browser.

And I’ve thought more about it in the context of writing Mac and iOS apps. Let’s consider a few apps I’ve worked on in my career:

NetNewsWire: an RSS reader that connects to any site with an RSS feed, no matter how that feed is served (http or https).

MarsEdit: a blog editor that connects to any blog with an external API, no matter how that API is served (http or https).

Glassboard: a private group messaging system.

Of these, only Glassboard would fit in an https-only world. Since we controlled the server, and since privacy and security were hugely important, requiring https would be no problem. (And of course we did use https.)

The problem is the other two apps. They all rely on the open web rather than servers controlled by the app writer. And it would be unacceptable to limit those apps to https only.

Let’s also consider my two secret-project Mac apps. Both of them need http access — they’re not limited to servers that I (or some corporation) control.

Since neither app will be sandboxed, I’ll be able to do this without Apple’s approval. My concern, of course, is that this situation won’t last. (It already means that there couldn’t be iOS versions of my secret-project apps — at least not without Apple granting an exception, which may be temporary.)

I’m totally on board with defeating the ability of the NSA and your internet provider and everybody else from snooping. I hate this snooping business — it’s anti-American and it makes me sick to my stomach for the future.

But I also know that the web isn’t going to switch to https quickly or completely. It’s expensive. To cut off http is to cut off the arms of the body of free speech.

Secret Projects Diary #1: Post-WWDC Notes

Note: This series — which will probably last a long time — is my attempt at writing about things without actually announcing what they are. I’ve decided I can eat this cake and still have it.

The point is not to tease — though I realize that that’s a side effect, and I apologize in advance. (It’s not going to stop me from saving actual announcements until the software is ready, and it’s not going to stop me from writing in the meantime. Because writing helps me think, and it’s fun.)

Swift

I started working on my apps a few months ago, and there was no question at the time that I should use Objective-C. But now with Swift 2 I wonder if it’s time to switch.

The new Swift goes a long way toward curing angle-bracket blindness. But, more importantly, now we know what Swift will be once it grows up (and it’s growing up fast) — and that thing, a protocol-centered language, is a thing I want.

(The most important session of this year’s WWDC was Protocol-Oriented Programming in Swift. It’s a peek into how we’re going to be writing software for the next decade and more. For the rest of my career.)

I haven’t written much UI code yet. Almost everything so far has been data transformations — isolatable things that run outside the main thread, things that could benefit from Swift structs and enums rather than the collection of classes that I’m currently using.

Objective-C is a living language, but Swift is the safer bet for the long term. And I want my apps to last a very long time.

I’m torn between wanting to make forward progress and wanting to port the code so far. I haven’t decided yet. I might do these things concurrently.

OS X 10.11 and Auto Layout

My apps will both require 10.11. That was never in doubt.

One of the interesting changes is that AppKit (with split views, particularly) has more of a concept of a sidebars and content lists. And there are some new behaviors, such as automatically hiding a sidebar and showing it as an overlay, that we get if adopt the new APIs.

At least one of my apps (and possibly both; undecided for now) will have a sidebar. But I wasn’t planning on using Auto Layout because I’ve had problems with performance, bugs (in NSToolbar), debugging, and with actually getting things to work the way I want. (I have not been able to replicate Mail’s splitview handling using NSSplitViewController, for example, but I can replicate it if I go the old-fashioned route.)

Auto Layout solves a problem I don’t have. I’ve been writing manual layout code for so long that I barely even have to think about it. It’s easy. While I understand the benefits of declaring (as opposed to coding) layout, those benefits disappear when things go wrong and when I can’t do the thing I want to do.

But this leads to a dilemma. Doing things the old-fashioned way means manually writing sidebars-that-overlay (and so on) and nailing the behavior perfectly and revising it every time the behavior changes. If I use Auto Layout instead, I get the behavior, and any changes to that behavior — but I also get an unknown set (of unknown size) of struggles and frustrations.

If it’s a tie, then the winner is the future-proof answer. Which is Auto Layout.

NSStackView

Stack views in 10.10 are slow. (I can point to multiple performance issues in shipping apps that are a result of stack views.) Word on the street is that they’re much-improved in 10.11 — which is great. If that’s true, then I want to use them.

There are lots of cases where a stack view is the best answer to a layout problem, and so I suspect there will be plenty of stack views in my apps. (As long as they truly are faster now. I haven’t checked yet.)

http deprecation

This one worries me a little, and I need to find out more. Since neither of my apps will be sandboxed, it may not be an issue.

But it’s a larger issue in the industry and is bound to have an impact on what I do sooner or later.

What upsets me about this issue in general is that it’s anti-democratic: it can make writing for the web more expensive and difficult for individuals. As a writer, reader, and open web partisan I dislike everything that shifts power away from people and toward entities with greater resources. What you end up with is corporate speech rather than the voices we know and love and need to hear.

This is a complex situation, though. I strongly believe in the right to privacy, and that encryption should be used much more widely than it is today, and that no organizations, official or otherwise, should have back doors.

Well. Anyway. More research and thought required on this one.

How Not to Crash Series Finished

All done. (At least I think so — I might think of more things, I suppose.) There’s a new page that links to all the posts. There’s a link to it at the bottom of every page on this site.

Archive

Ads via The Deck