You know what would help tablet (read: iPad) sales? More support from third-party developers. Most iPhone app launches snub the iPad in the same way they snub Android. The response to the question is the same: “Maybe some day.”

I was pleasantly surprised to see Instagram’s new Hyperlapse app launch on both the iPhone and iPad today.

Using Command-C with Launch Center Pro

Like Pastebot, Command-C lets you send the contents of your clipboard back and forth between your Mac and iPhone. You can also use it to send stuff between your iPhone and iPad. Best of all, it supports x-callback-url, which means you can use it with Launch Center Pro.

Here’s the Launch Center Pro action I use to quickly toss my clipboard to another device. Instead of having a separate action for each device, it lets me choose the target device from a list.

command-c://x-callback-url/copy?deviceName=[list:Choose Device|Mac=bluepolicebox|iPad=MiniMe]&x-source=Launch%20Pro&x-success={{launchpro://}}

Install this action. (Be sure to update the device names to match your own.)

I have a separate action that let’s me send freeform text to another device as well:

command-c://x-callback-url/copyText?deviceName=[list:Choose Device|Mac=bluepolicebox|iPad=MiniMe]&x-source=Launch%20Pro&x-success={{launchpro://}}&text=[prompt-return:Text to Send]

Install this action. (Again, be sure to update the device names to match your own.)

Got any other nifty Launch Center Pro tricks? Post them to Twitter with the hashtag #lcptips.

Playing with URLs in Launch Center Pro 2.3

This morning, I found myself wanting to clean a URL with Clean Links and then send the cleaned URL to another Launch Center Pro (LCP) action. You can chain LCP actions together now using the [action:##] tag that was introduced in LCP 2.3. This wasn’t as straight-forward as I had hoped it would be, but the solution I came up with works really well. I’d love to see if there’s a simpler implementation.

The workflow looks like this:

  • Copy URL
  • Open LCP and fire the clean-link action
  • Clean Links strips the cruft out of the URL, places it on the clipboard, and returns to LCP
  • LCP then calls another action to do further processing on the contents of the clipboard

Here’s what the resulting LCP action looks like:

clean-links://x-callback-url/clean?url=[clipboard]&x-success={{launch://x-callback-url/clipboard/?text=[clipboard]&x-success=[action:10]}}

First, we pass the URL on the clipboard to Clean Links. It passes back the cleaned URL on the clipboard and returns to LCP via the x-success parameter.

From there—and this is where it gets hacky—we tell LCP to call an internal function (/clipboard/) to place the current contents of the clipboard onto the clipboard. This is necessary so we can then use the x-success parameter to call action number 10, which is what we’re really after.

Again, very hacky, but if you need to do something like this, it works really beautifully. If theres a better way to do it, I’d love to hear about it (@jeffmueller on Twitter and App.net).

Update: Here’s a much simpler version:

clean-links://x-callback-url/clean?url=[clipboard]&x-success={{launch://?url=[-action:10]}}

Thanks to Eric Pramono for the tip!

Apple, iOS, and Leading by Example

When the App Store launched in 2008, I started to worry about where the newly-christened iPhone OS (which would later be renamed iOS) was headed. While I was excited about the prospect of third-party native software on the iPhone, I was concerned about where iOS might eventually find itself in the not-too-distant future. It was the first move toward becoming a regular-old operating system. Given the history of Windows and Mac OS, that carries certain implications. Layers of cruft. Useless features. Bloat. Poor software. Bad stewardship.

Flash forward five years, and I think we’ve found ourselves faced with a mobile operating system that exhibits all of those problems and more.

The App Store has become a mess of black-hat SEO techniques, rip-offs, cons, and poorly architected applications that show a total disregard for common QA practices. It has all of these things despite being a much-maligned walled garden, and it’s been this way for a long time now. The built-in search doesn’t work well despite being reworked several times (including once using technology that was snapped up via the acquisition of a company that specialized in searching the App Store). New app releases can take hours to propagate through the store for seemingly no reason whatsoever. Apple seems content to let the App Store fester.

Apple’s own software has been bug-ridden for some time. iOS 7 was—and remains—full of issues. Even seemingly basic applications like Reminders fail routinely for people. Duplicate contacts scattered across devices. Voice Memos that randomly refuse to play.

iCloud continues to be unreliable despite being almost three years old, which has led many third-party developers to build their own completely unreliable sync services. iCloud file storage remains a black box of data that users can’t see into. Apple still eschews iterative development and ships updates to its web services on (what appears to be) a yearly basis, meaning any issues users face will be present until the next big reveal.

iCloud storage plans are expensive even by Apple’s standards and top out at 50 GB despite the largest iOS device carrying 128 GB of storage, which means some users with a full device can’t use iCloud Backup despite paying a premium for the highest tier of storage. People still don’t understand that Photo Stream can and will quietly delete your photos based on arbitrary limits. Data loss is common in both cases.

iOS hasn’t grown in a meaningful way over the last couple of years. Yes, it’s gotten better for developers, and lots of nifty (but currently useless) things like iBeacons and peer-to-peer networking were added, but users haven’t gained much more than a pretty interface that makes buttons hard to discern. Apps still can’t share data with each other. AirDrop on iOS can’t talk to AirDrop on a Mac, which is baffling.

The iPhone and iPad are both beautiful examples of industrial design, though. I’m sure the next versions will be every bit as nice. But good hardware with bad software still leads to a half-assed product. Other hardware makers are getting better at industrial design. Good hardware is no longer enough to separate iOS devices from the rest of the market.

But the thing about the rest of the market is that all of it is objectively worse than iOS. Android has privacy issues that are too numerous to count. Windows Phone remains a confused OS with a poor selection of third-party software.

Unreliable software and services. Complacency. Privacy concerns. Bad stewardship. Confusing user experiences.

The best of the best is, at the moment, face-planting in grand fashion. iOS’s platform issues are so entrenched that driving them back could take years. And the alternatives to iOS are non-starters to those who care about a solid ecosystem and some semblance of privacy.

To me, the early promise of mobile computing has been broken. The iPhone took off like a rocket and replaced everything from the calculator on your desk to the flashlight in your closet. And then it got weird. And confusing. Simple things that technology was supposed to make easy (e.g., managing your to-dos) became a game of Russian Roulette with a server farm in North Carolina. That’s not how things were supposed to go.

I’ve personally dealt with this by slowly backing away from using computers to do important things. Not just mobile devices, but computers in general. The trust I had in my devices has eroded slowly over the last seven years. Despite wanting to be paperless, I’ve found myself turning to notebooks, post-its, and analog tools like whiteboards that won’t mysteriously go missing in the night because someone tripped over a power cord halfway around the world.

It saddens me because of the potential of these devices. Our phones and tablets are powerful and capable of so much, but they continue to fail us because of bad software. It’s easy to blame third-party developers, but I think it makes more sense to blame Apple for doing a poor job of shepherding the platform along.

They set the standard by which iOS software should be measured, and they control the primary mechanism of distribution. If Apple ships bad software, why should other iOS developers care to do better? And if the App Store encourages bargain basement pricing, scammy in-app purchases, and generally deceptive marketing practices just to make your app visible via the built-in search, why should we blame developers for doing what’s required to turn a profit? Bad begets bad.

Rumored iOS features used to excite me; now they frustrate me because they point to Apple taking on still more responsibilities. As a developer for and a user of Apple’s products, I hope they’ll reign in their focus soon. We don’t need a new TV or a wearable device. We need an operating system and an App Store and web services that are reliable enough to restore our trust in the platform. We need Apple to set a better example.

Plink - Not Just For Bloggers

The little app I’ve been working on is proving to be more interesting than I originally envisioned. I wanted something to help with blogging, but once I built in full support for x-callback-url, I found a few more uses for Plink.


The above video shows how you might use private photo storage and Day One’s new Publish feature to take on a 365 project.1

Launch Center Pro calls Plink and passes an x-success URL that tells Plink to hand the URL of the uploaded image off to Drafts. Drafts calls an action on itself, which generates a Daily Photo journal entry from a template using the URL passed in from Plink. Once the template is assembled, it’s handed off to Day One, and my journal entry is complete.

Plink’s role is to be as close to invisible as possible, and I think it does its job admirably.

I really want to see what other stuff people can do with Plink. The Backer campaign has a little over a week to go, and we’re pretty far short of our goal. If you think Plink looks like a useful app, we’d really appreciate it if you’d consider kicking in a few bucks or helping us spread the word on Twitter or App.net. Thanks. <3


  1. A 365 project, for those who don’t know, involves taking a photo a day and sharing it with people. 

Using Markdown Tables with Day One and Launch Center Pro

Markdown Tables

Update: After writing this post, I built a tool to help encode these templates. See the bottom of this post for more info.

After posting my Beer Log action for Launch Center Pro yesterday, I got a couple of questions about how to generate those pretty tables in Day One.

Day One has extensive support for rendering Markdown. In fact, it supports MultiMarkdown, which is a superset of Markdown that includes some additional goodies like footnotes and—most importantly—tables.

Even though you can create tables with Markdown, most people don’t. The syntax is really quite ugly. Here’s an example:

| First Header | Second Header |         Third Header |  
| :----------- | :-----------: | -------------------: |  
| First row    |      Data     | Very long data entry |  
| Second row   |    **Cell**   |               *Cell* |  
[simple_table]

Ew.

The inimitable Dr. Drang wrote a detailed explanation of Markdown tables, so I’ll link to that here rather than try to write my own explanation. His is quite good.

Deconstructing the coffee log

The raw Launch Center Pro (LCP) action that Ben Tsai released is URL-encoded. It has to be in order for LCP to understand it. For us to customize it, it would help to decode it. You can do this in one of several ways. TextTool for iOS has encode and decode functions. For creating the Beer Log, I used this web-based tool by Eric Meyer.

Here’s the original Coffee Log after decoding:

dayone://post?entry=#coffee #log

|Coffee||
|:---|:---|
|Origin/Name|[prompt:Origin/Name]|
|Brew method|[list:Brew Method|AeroPress|Chemex|Drip|Espresso|French Press|Pour Over|Other]|
|Brewer|[prompt:Who brewed it?]|
|Rating|[list:Rating|★☆☆|★★☆|★★★]|
|Notes|[prompt:Notes]|

Now that we can read the Markdown table syntax, customizing the table is pretty straight-forward. Note the fields inside square brackets. Those are specific to LCP.

Before installing it in LCP, you’ll need to re-encode your action again once you’re done tweaking it. This is where it gets tricky.

Re-encoding

You can’t just re-encode the entire string. Looking back at Ben’s action, parts of the URL are encoded, and other parts aren’t.

%7CBrew%20method%7C[list:Brew Method|AeroPress|Chemex|Drip|Espresso|French Press|Pour Over|Other]%7C%

If it were completely encoded, it would look like this:

%7CBrew%20method%7C%5Blist%3ABrew%20Method%7CAeroPress%7CChemex%7CDrip%7CEspresso%7CFrench%20Press%7CPour%20Over%7COther%5D%7C

See the difference? It’s the square brackets (and everything inside them).

If the square brackets end up encoded along with the rest of the string, LCP won’t understand it. You won’t get any prompts or lists, and your action will silently fail, or the app will throw an error.

Instead, you’ll have to encode your string piece by piece. Encode everything that isn’t inside square brackets, and piece your URL together.

Yes, it’s a pain, but I haven’t found an easier way to go about it. You’ll probably have to debug syntax errors along the way, but if you’re careful, it shouldn’t take long to get the hang of it.

Update: This app can handle the encoding for you. You can build your entire table in the editor, then click the Encode Template button. Code for the app is available on GitHub.

I’ve been writing with my iPad for a while. Almost every post on this site was written with Editorial. I even built a custom workflow to post to Tumblr directly from the app. And so far, I’ve been including screenshots using an adapted version of Federico Viticci’s image upload script.

It works well, but this sort of thing isn’t accessible to everyone. It’s too fiddly to set up, it requires looking at and sometimes editing code—it’s difficult. And while blogging from an iOS device is currently a small topic with a limited audience, I think there’s a broader audience who would be interested in it if it weren’t so difficult to do.

The fact that it’s non-trivial irritates me. For a device that Apple touts as being immensely capable, something as simple as blogging should have been solved on day one. When a person is judging whether or not to adopt a platform, the decision can often come down to things that seem trivial.

I really like the iPad. I want to see more people using them. So I’m building Plink to make blogging from an iOS device easier for those people who’ve tried and found it to be too difficult. For me, the biggest annoyance has been dealing with images. Uploading them, getting a link to them, inserting the link in my document, etc. Plink takes care of that.

You could say that Plink is a feature, not a product. You’d be 100% correct. And honestly, if an enterprising app developer wanted to build a wonderful blogging application that fits all of my needs (including the functionality that’s in Plink), more power to ‘em. I’d buy it (or back their Kickstarter or Backer campaign) in an instant.

But until then, Plink could fill a small gap in a small workflow used by a small set of people. And if it eventually convinces a few more people that an iPad can be used as a primary writing/blogging device, I’ll be pretty stoked.