When I need to load a view controller from a Storyboard I like to create an extension to the view controller’s class and add a class function to it that does the work. It keeps things looking clean in the code where you use it.
I’m not sure if this is smart or dumb. I’m sure very smart people will let me know. Here’s an example.
Here’s how you’d use it in your code.
I got an email from Apple a week or so back letting me know I needed to upgrade one of my apps to 64-bit. I knew right away it was Arrgly but wasn’t really sure if I wanted to update it.
On Sunday morning I received an email from an Arrgly user asking if I was going to update it because he likes the app. It felt good to know someone else found my goofy app useful. I decided at a minimum I’d publish a little framework someone else could use to write their own version of the app if I couldn’t get to it, or couldn’t finish it on time.
It took less than an hour to create the project and get it published. If you’re doing Mac or iOS development and you need to shorten or expand URL’s for a YOURLS based service you’re welcome to use YOURLSKit. It’s all Swift 3 but should be fine with Swift 4 projects and iOS 11 or macOS High Sierra. It’s a tiny bit of code, but it does the job.
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.
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?
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.
Every 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.
Nobody making $ on 1) Watch apps 2) TV apps 3) Mac apps or 4) iMessage apps. Apple has one profitable dev platform. https://t.co/jVgXmAAHhS
— Michael Love (@elkmovie) December 18, 2016
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.
In the last year PCalc’s revenue breakdown has been 78% iOS (72% full app outright, 6% via IAP in Lite), 21% macOS, and effectively 0% tvOS.
— James Thomson (@jamesthomson) December 18, 2016
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. 😀
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?
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.
The 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.
Future self. If you run into this error when trying to run a build.
dyld: Library not loaded: @rpath/libswiftCore.dylib
Do a Project > Clean, then rebuild. Worked this time around.
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.
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:
https://twitter.com/stroughtonsmith/status/779726806727491584
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.
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.
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.