Scripting iOS

Last week Apple acquired automation workflow application Workflow. Of course there was a nice buzz around it and it was a big topic of conversation on various podcasts and websites.

This, of course, got me thinking about automation. I’ve always been a fan of open API’s and the ability to automate applications. We’ve also seen recently that Omni Group is opening up OmniGraffle to automation via JavaScript.

Back in 2010 x-callback-url was created as a way to allow applications to call into each other and return results so you could chain together calls to build custom workflows. Apps like Launch Center Pro and Workflow took advantage of x-callback-url to let you build those workflows and execute them. Now we have a bonafide standard, without a standard. The app ecosystem found a way to support automation without Apple’s help.

I’ve used Launch Center Pro but until recently I’d never used Workflow, and it’s pretty amazing. The Workflow guys did an amazing job creating a drag and drop UI for building what amounts to a program. Well worth a look.

So, this brings me to what I’ve been thinking about over the past few days. Given x-callback-url and App URL schemes in general it would be extremely cool to use those to create object hierarchies using JavaScript. Why JavaScript? Well, it’s native to iOS and applications can use the runtime. Given the advances made by the Workflow team why not take it one step further?

Allow applications to specify a  Scripting Dictionary or Type Library as part of the application bundle, this should allow runtime creation of objects. I know this isn’t rocket science and it’s been done many times over.

Short of adding support to the OS it would be pretty sweet if an App like Workflow, Launch Center Pro, or Pythonista would standardize on a way to parse a URL Scheme into an Object Hierarchy.

I’m going to use Evernote, Bear, Overcast, and Arrgly as examples.

What do you mean by Object Hierarchy?

That’s a good question. Here’s what I’m thinking. Since the Apps mentioned above all support URL Schemes we can derive an Object Hierarchy from them. Basically the beginning of a URI begins with a scheme. The scheme is the name. In the case of Evernote it’s evernote. Pretty simple, right?

Given the scheme name we follow that with a path. In the case of x-callback-url based URL schemes we will skip over that part and move to the second item in the path. This will be the action, or function, or the object we’re going to execute.

evernote://x-callback-url/new-note?type=text&title=EC%203

The above URL will tell Evernote to create a new note of type text with a title of “EC 3”. If we had a way to parse that in a runtime application we could present the user with an Object that has methods that take arguments, like this.

evernote.new-note(type, title)

Let’s do a couple for Bear. First the URL Scheme.

bear://x-callback-url/create?title=My%20Note%20Title&text=First%20line&tags=home,groceries

Now translated into code

bear.create(title, text, tags)

Overcast URL Scheme.

overcast://x-callback-url/add?url=

Code

overcast.add(url)

And finally, my favorite, Arrgly URL Scheme.

arrgly://shorten?url=

Arrgly Code

arrgly.shorten(url)

Pretty simple to turn all of those into objects. When I say you can create a hierarchy it means you could, by convention, lump groups of actions into objects, or like the above examples have a set of actions that all live on a single object.

Here’s what a object might look like as a URL Scheme.

thing://x-callback-url/document/add?title=
thing://x-callback-url/document/delete?id=

That would result in using it like this

thing.document.add(title)
thing.document.delete(id)

Of course this need more fleshing out and it would require app developers to decide on a well known convention to make it work as expected, but it could be done with a bit time and effort. It could be these become an extension of the x-callback-url specification?

Passion Project: Update #2

Back in November I talked a bit about my passion project. I’ve rewritten the Pharmacokinetics Math library for RxCalc in C++ and I’m rewriting the UI completely in Swift. It’s been a real blast. My November update talked about bringing C++ and Swift together with a tiny layer of Objective-C++.

Over my holiday break I didn’t code as much as I wanted to, but I did manage to get some done. Since returning to my day job I’ve felt a bit more excited about working on the RxCalc update at night. I don’t know why, I just have.

I now have the new mixed Swift, Objective-C++, C++ based app in a working state, but I have a lot of polishing to do as well as adding some new features. Of the remaining 1.x features I have to implement is Options. Once that is complete I’ll move on to adding IAP, Theme, and 3D Touch support.

I really love working in Swift. The code base feels so tiny compared to its Objective-C counterpart. Not that Objective-C is bad, just different.

Next up? The Android version. For that I need to spend some quality time with JNI.

I’m not in any shape to ship this release, but it’s getting close by the day.

App Stores

A snowflakeEvery once in a while developers drop interesting nuggets of information on Twitter or their weblogs on the state of Apple App Stores and how they relate to their businesses.

In late November longtime Mac and iOS developer, Panic, announced they would discontinue Status Board.

“First, we had hoped to find a sweet spot between consumer and pro users, but the market for Status Board turned out to be almost entirely pro, which limits potential sales on iOS — as we’ve learned the hard way over the past couple of years, there’s not a lot of overlap right now between “pro” and “iOS”.”

Panic is a shop I look to for direction and inspiration. They build solid, beautiful, easy to use applications. Their ratio of Mac to iOS Apps is pretty interesting. Their main Mac applications; Coda and Transmit, are aimed squarely at professionals. If you look at their remaining iOS applications two are complimentary to their Mac counterparts; Coda and Transmit, and the third, Prompt, is most likely built using code and knowledge gained from their other apps. That is not meant as a criticism. It makes total sense. Coda and Transmit are their big dogs, why not make iOS versions of them? I’m looking forward to Panic’s year end report. The last two have been amazing reads.

This morning as I was scrolling through my Twitter timeline, trying to avoid political talk, I noticed an exchange between Michael Love and David Barnard. As suspected, iPhone is the money maker and iPad is not pulling its weight.

Not long after that exchange I saw a nice tweet from James Thomson, of PCalc fame. It looks like the iOS App Store is his primary source of income.

Depending on the podcast I’m listening to, Core Intuition vs. Accidental Tech Podcast, I’m either excited about the state of the Mac or completely bummed about it. Regardless, it feels like Apple is pushing the iPad toward the Prosumer market and keeping the Mac alive for Professionals, mainly those creating iOS Apps (Hey, we need a platform for creating apps, right?)

Having said all that, I’d still like to take a shot at the Mac software market. I don’t need to make millions, but it would be nice to make hundreds. 😀

Passion Project: Mixing C++, Objective-C++, and Swift

I know a lot of folks have had to go through the process of bridging to C++ so you can use it from Objective-C or Swift. In my case I’m using it from Swift, so I thought I’d share what the middle Objective-C++ layer looks like. If you’ve done any Objective-C it will look like straight Objective-C, until you look a little closer. That’s when you’ll notice a C++ namespace, new, and delete statement. This code is a straight passthrough to the underlying C++ code — it’s here so Swift code can communicate with the C++ code.

Here’s the code that bridges to our Creatinine Clearance calculation.

You’ll notice a class called PKMConvert that has a class method called genderFromPKMGender. I created a set of mirror enums. One on the iOS side the enums use NS_ENUM syntax, on the C++ side they’re straight C style enums, so this code converts between the two. It’s just a simple mapping.

Another thing you’ll notice is I’m still using “old” C++ syntax to create and destroy objects. I’ve been thinking about updating the syntax to C++11 so I’d use unique_ptr instead. We’ll see if that happens. It’s not a big deal.

Something I’ve been mulling over is releasing the entire PKMath C++ Library as an open source project once I have it working for iOS/Mac, Android, and Windows. I don’t know that it would be overly useful for anyone, but there you go.

Since I haven’t actually written any Swift code in the new RxCalc to use the Objective-C++ code I thought I’d share one of my unit tests for the Creatinine Clearance example above.

Here’s how the different layers look from 30,000 feet. I like pictures, don’t you?rxcalc2layers

Passion Project: Update One

I’ve made a couple runs at the freelance iOS developer life. The first time things went really well, but I was offered a gig by one of my clients and it too good to pass up. A couple years into that position — leading a team developing a Windows video decoding SDK — I got the itch to go back to iOS and the Mac. Around the same time our oldest daughter decided she wanted to move back to California. I took a week off to help move here, and think on this idea of going back out on my own. I decided to give it a go. This time around I failed, miserably.

My attempts to go indie have always been predicated by a desire to develop a product. I thought I could bootstrap my indie life doing freelance work. This was definitely a mistake. Once you start doing client work you’re on that hamster wheel of how do I get my next client? Drumming up work is difficult. I failed at that and I’m also a slow developer. I don’t crank out code quickly, which you need to be an effective freelancer. Get it done so you can move on to the next deal.

When I finally found a full time job I decided I’d work on passion projects and see how that worked out. I’ve had many starts and stops on various projects, but I keep coming back to RxCalc. It was my first iOS app. My brother, Jerry, and I worked on it together. Jerry is a clinical Pharmacist and wanted an iOS app to help him do Pharmacokinetics Calculations. He did all the math and designed the workflow and I turned both into Objective-C. We shipped in June 2009 and RxCalc went live in the store July 4, 2009 (nice bonus.)

I’ve been slowly working on a rewrite of RxCalc. My first iOS app was messy, but it has proven stable — I haven’t had a crash report since the 1.0 release in 2009 — but the code is cringeworthy. I’ve cleaned it a bit over the years as well as shipping a 1.2 release that included some new functionality. That release included much cleaner code, but I’ve wanted to add IAP to it for additional calculation models and port it to Android, and maybe even a Universal Windows App.

When Jerry and I originally started developing what was to become RxCalc it began life as a Palm app in C++ and the Pharmacokinetics math library was portable C++. It built on Palm, Windows, and iOS — it built first time on iOS with zero change. When I was learning Objective-C I decided it would be best to port PKMath from C++ to Objective-C. That was really easy. It didn’t take long at all.

Here we are in 2016 and I decided I’d better get started with my grand plan to make PKMath portable, again, and build for iOS, Android, and Windows. Why? Just because. Remember, this is a passion project. I don’t make any money on RxCalc, but I do have a plan to change that with this new version.

Will write C/C++ for foodThe new C++ PKMath library is written. I’ve built a small layer of Objective-C++ over the top of it so I can write the new UI in Swift. The old RxCalc was 100% Objective-C, the new one will be a mix of C++, Objective-C++, and Swift. That sounds kind of weird, but there is a means to an end.

Android is my next target. I’ve started working on JNI wrappers around the PKMath library. This has proven to be extremely difficult. It’s going to take some time to wrap my brain around how this all works. I’ve managed to write a simple sample that uses PKMath to calculate an Ideal Body Weight and display it in an Android view, but that’s as far as I’ve gotten.

As for Windows it’s the thing I’m most familiar with. I’ve spent most of my 25+ years as a developer building Windows applications. The downside is I’ve never built a Universal Windows App and I’m not sure how to properly build PKMath for it. I’ll figure that one out and I imagine it will be as easy as wrapping C++ in Objective-C++.

Progress is slow and I’m easily distracted. We’ll see how it goes. More updates to come.

P.S. — I find Swift to be the most enjoyable language I’ve ever used. Doing the new RxCalc UI has been a lot of fun.

Apple Watch in the Hospitality Industry

Eater: “When Meyer’s 30-year-old Union Square Cafe reopens in Manhattan next month, every floor manager and sommelier will be wearing an Apple Watch. And when a VIP walks through the front door, someone orders a bottle of wine, a new table is seated, a guest waits too long to order her or his drink, or a menu item runs out, every manager will get an alert via the tiny computer attached to their wrist.”

This is pretty nifty. One thing I notice when I’m moving about, doing something physical, I may miss taps. It’s rare, but it does happen on occasion.

I’ll be keeping an eye on this.

Future macOS Frameworks

Duct Tape, fixer of all things!I stumbled upon an interesting conversation between some well know Apple Ecosystem Developers this morning discussing, maybe lamenting, the lack of UIKit on macOS. I’m afraid I may have pushed these fellas to take their conversation private, I am sorry if that was the case.

Here’s the tweet that started the conversation:

I’m not known in any development communities. I’m what you’d call a nobody. But I’m a nobody with years of experience that has seen changes to my development ecosystem.

Having experienced a dramatic shift in Windows Development technologies I have opinions about what I would expect to see from Apple. These opinions and $10.00 should be enough to buy you any item on a Starbucks drink menu. Take if for what it is. An opinion of a nobody.

What I Expect

Given Apple’s love and focus on Swift I fully expect Apple to put their effort into moving their frameworks to focus on Swift while continuing to allow App developers to use Objective-C with anything new. I’ve written about the idea of Swift only Frameworks. I believe we will eventually arrive there. For now we have excellent UIKit support for three different devices; iOS, watchOS, and tvOS. Odd man out would be macOS. It doesn’t make sense, at least to me, for Apple to spend time back porting or adapting UIKit to the Mac. Their bread and butter is their  iOS based trio of the phone, watch, and cable like device. Since iPhone accounts for around 60% of revenue it makes sense for the iOS Platform to be their primary focus. That begs the question, will the Mac ever receive the attention we’d like it to receive? Probably not.

In the end I’d expect Apple to push iOS forward while keeping the Mac as a primary development system for iOS, watchOS, tvOS, and macOS developers with the latter receiving very little attention from a new Frameworks perspective.

A Brief History of Windows Development

Like I said above, I’m opinionated and I’ve been around the block a few times. I know Apple isn’t Microsoft and people tend to hate those comparisons. But I do see similarities between the Microsoft of the 90’s and the Apple of today. That’s a discussion for another time.

The discussions around Frameworks reminds me of Microsoft’s transition to .Net and C# as an easier way for developers to create Windows Apps. Apple is making such a big push with Swift a new framework targeting Swift developers feels like a natural progression.

It’s taken over 15-years to really push app development into a .Net world. I suppose some could argue it took less than 10 and I wouldn’t fight that. The point is Microsoft managed to push an entire development community to a new technology while allow old technologies to continue to not only function but grow. Look at the Microsoft Office Apps and Adobe Photoshop among others. They continue to be very relevant today and continue to add new features while the Windows API receives much less attention than does .Net and C#.

Ultimately the point is I know Apple could choose to push toward a Swift only framework and allow legacy Objective-C/Cocoa apps to continue to grow and thrive. Microsoft is a prime example of how a company could pull it off.

I think it’s kind of nice being a new developer to Apple’s platforms. I don’t have 20+ years of baggage like I do with Windows. It’s been so much easier to move from Objective-C to Swift because of it. Well, that and being most familiar with C++ made the transition to Swift feel more natural to me.

Whatever Apple has in store for us, be it the growth of Cocoa, a new Swift centered framework, or a Swift only framework, I’m ready for it and welcome it.

Vesper: A Post Mortem

A wonderful bouquet of flowers.John Gruber: “What went wrong was very simple. We never made enough money. Why we didn’t make enough money, what we should have done differently to make more money — those are complex questions (which I’ll tackle below). But what actually sunk Vesper was not complicated. Even as a relatively popular app at a relatively high price (for iOS), revenue was never high enough. Brent took a job at the excellent Omni Group in September 2014, and from that point onward the writing was on the wall. We could have, and probably should have, shut Vesper down a year ago. But we loved it too much. Or at least I did.”

Brent Simmons: “This is the last app on the App Store where I wrote all (or almost all) of the code. Odds are excellent that there will never be another app written largely by me on any app store.”

It’s hard to make decisions like this. Vesper was the result of a lot of hard work by a small group of dedicated people. Vesper will be missed, by them the most.

The most fascinating part of this entire post mortem from John and Brent is the belief that creating a Mac App first may have lead to success. Obviously these guys know their Mac brethren better than I, but I always thought a subscription model was a better option for them, and I wrote about it in 2015.

I think the idea of a sustainable business is the right way to look at this, but pricing an app at $9.99 isn’t the proper solution. The proper solution is to charge for their “fast, reliable, unlimited sync.” That’s the value, the app is just a way to get to your data.

Obviously there are a few really great companies out there making a go of it but the market has changed so dramatically from the time Brent started Ranchero. At the time the Mac wasn’t nearly as popular as it is today and the App Store model didn’t exist. Sure, you still needed a great product and had to work hard to get the word out, but people still understood the value of software. Today iOS and Mac Apps have been reduced to commodities and commodity pricing. Most people expect free and get it from companies that make their money other ways, including services, which is why I think the service is the most valuable component. Does it mean you should only do services and not native clients, no. The client side provides the great experience and the service opens the door to the magic of data flowing from one point to another. Without both sides you can still have a great experience but it may not be as great as it could be.

Thanks John, Brent, and Dave for giving us Vesper.

Post Mac Apple

Recently Vivek Wadhwa of The Washington Post wrote:

Apple should release a version of iOS for non-Apple devices. This suggestion will seem like heresy to the brand’s loyalists, but it may be necessary for the success of the company.

Imagine those Samsung, LG, and Xiaomi smartphones having an original Apple operating system on them rather than the imitations they are presently running. Offered the choice, users would upgrade in droves. And those users would download new applications and sign up for Apple’s subscription services, giving the company a cut of everything they purchased, as well as valuable data and marketing opportunities. Google’s Android business would finally have a formidable rival.

First off, I don’t think Apple is in bad shape because they own less of the mobile market than Android. In fact, they make more money than all Android devices combined. So the thought of being a formidable rival is kind of moot, but that’s not what I wanted to write about, just an observation.

I think macOS would be a much better OS to OEM. Why? Well, Apple is paying so much attention to iOS based devices, the iPhone in particular, they’ve ignored their laptop and desktop computers for a very long time. In fact most of their computers are rated Don’t Buy by Mac Rumors.

Mac Rumors
Mac Rumors

Of course they’ve tried this before. Before Steve Jobs returned in 1997 Apple had OEM’d Mac OS to a few partners. Those partners were doing fine at the expense of Apple. When Jobs returned it was one of the first things he killed so Apple could focus on their core business, the Mac. Fast forward 20 years and Apple is as unfocused as ever. They’re building all kinds of stuff looking for the next iPhone. Here’s a hint Wall Street, I don’t think you’ll get another iPhone-like success for many, many, years.

Anywho, back to macOS on other hardware. Since Apple hasn’t shipped new Mac hardware for professionals in a long time professionals have either created their own solutions or switched to Windows or Linux. Yes, people are switching to Windows because their Macs are not up to the task. Those of us that live on the platform feel strongly about it. I love using the Mac and macOS to do my work but most people just see it as a hammer. They don’t have an attachment to the OS or the hardware. If you can get a PC with Windows that blows the doors off a Mac Pro and your production software runs fine on Windows, why not switch?

What if there were another solution to the problem? What if Apple selected a single OEM and allowed them to create high end hardware that runs macOS? That’s what I’d prefer to OEM’ing iOS to other mobile phone makers. The professional market may appreciate it too.

I know the iPhone and iOS are killing it revenue wise. That idea seems to be the driving force behind Mr. Wadhwa’s piece, but it would be really nice to have alternative hardware designs that don’t focus purely on thinness and lightness. I still love my SUPER FAT 15in 2011 MacBook Pro. It’s perfectly suitable for people creating iOS Apps or small Mac Apps. Folks editing Audio and Video or making movie magic the likes of Pixar and ILM need powerful computers. I’m sure they’d appreciate faster Macs every year or an OEM that could deliver faster, specialized, expandable, repairable, Mac alternatives running macOS.