Tuesday, May 24, 2016

Swift and Objective-C

There have been a ton of discussions and think pieces written on this topic, but I wanted to get my thoughts out there in a longer form than 140 character blurbs.

Think pieces? Yes, think pieces. Almost every argument for dynamism or keeping Objective-C’s better parts are making one of the following assumptions:
  • Apple has no interest in dynamism in Swift.
  • Apple has no concept of what Objective-C can do and why it’s beneficial.
  • The Swift Core Team isn’t made up of some of the smartest people out there.
  • There are no plans to create a Swift-based version of the frameworks.
  • Objective-C is being phased out.
  • Swift only exists to make iOS/Mac apps.
And so on. Thing is, this is Apple. They kept Swift secret for years before they told us about it. There’s a longer-term plan at work, I’m certain of it.

Is Objective-C dead? Hardly. Is Swift complete? Again, hardly. Can they coexist? Certainly (though sometimes with a bit of pain). Is Objective-C going away? Doubt it. In fact, it would be utterly naive to think so. Dynamic features in Swift are coming, it’s been mentioned by People in the Know™. Native frameworks are coming, just not immediately (a stable API and a stable ABI are higher priority).

Last, but certainly not least, is that Swift is a cross-platform language. What’s good for the language isn’t necessarily what’s good for UIKIt or AppKit. This is a tightrope the Core Team must walk, figuring out how to manage the language, the open-source process, Apple’s plans, future-proofing, and tons of other factors. They are incredibly smart, but they are limited in number. This all can’t happen overnight and I’d argue strongly that it shouldn’t. For the next major release (or two), I’d expect a focus on stability.

Either way, I doubt your complaints aren’t being heard. There’s a lot of noise and there are people traversing the chaos. Relax. It’s coming. This is only possible because Objective-C is so stable and provides a solid foundation (pun intended). Your toolbox isn’t limiting you–it’s stronger than it has ever been.

Update: Chris Lattner on dynamic dispatch

Update: Wil Shipley on this whole thing

Tuesday, April 5, 2016

TextExpander and Subscriptions

I, like many of you, were caught off-guard today when it was announced that TextExpander from Smile’s latest version was moving from a traditional software model to a subscription service. I was perturbed, but since TextExpander is so integral to my workflow, I bit the bullet and upgraded things to the new version (for nearly $50/year). My reasoning was that I already had everything in place and configured and I required the iOS integration. And thus, I paid for a service I didn’t actually need or want.

There’s an argument to be made that TextExpander is utility software only and this type of subscription is a hard sell to users:

And, perhaps, Smile could have learned a bit more from how (wonderfully) AgileBits handled its recent upgrades for 1Password. The difference here is that password sharing between family members and organizations is a problem people have and 1Password found a way to solve it. The ability to share snippets between members of an organization and edit them on the Web? Not convinced this is a problem that needed solving.


(I’m aware there are other options, but this is the one for which I’ve had experience and a paid license.)

In the past, I was a Typinator, rather than a TextExpander, user and I have an existing Typinator 5 license I can upgrade to version 6 for less than $15. The feature-gap between TextExpander and Typinator has closed (and is potentially non-existent). Advanced features such as fill-ins, snippets that run scripts, snippets that contain other snippets, snippets that perform calculations, etc. are all available now. This leaves the elephant in the room…

iOS Support

As a user, I’ve liked the fact that many of my apps support TextExpander so I can easily share snippets and functionality across my devices. As a developer, I’ve spent time adding TextExpander support to my apps for the same reasons. Over time, however, things have changed. Apple added keyboard Text Replacement (née Keyboard Shortcuts) back in iOS 5 with iCloud sync in iOS 6. In recent iOS updates, Apple has made it more difficult for apps to integrate with TextExpander now requiring each app to keep a copy of the shortcuts library and provide an interface to manually sync them from TextExpander. When custom keyboards were added in iOS 8, TextExpander added a keyboard to help solve this problem, but, in practice, this feature is less than ideal and falls (far) short of Apple’s system keyboard.

I’ve been thinking about how I use TextExpander on iOS and it generally matches this tweet by my pal Pedro:

The short answer? I don’t depend on TextExpander on iOS as much as I thought. Apple’s Text Replacement meets 90% of my needs (and works nearly universally) with synced Safari preferences, iCloud keychain, 1Password, Workflow, and a few choice extensions filling the remaining 10%.

Future Development

I haven’t yet made a decision on whether I will continue to support TextExpander in my apps going forward. Obviously, I’m not going to tear it out in a fit of rage from existing apps, but for something forthcoming like TextTool 2 where I haven’t yet integrated it, the decision is murkier.