Swift + Javascript

Unlikely Friends

Jordan Morgan
Oct 4, 2015 · 5 min read

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

I had a hunch, you might call it, that this last week would be filled with new experiences for me. A new job, new friends, going 100% remote — change and fresh experiences are part of the deal when one changes career paths. My first week at Buffer was filled with many amazing things, but one was quite unexpected:

Using JavaScript to code out my first feature for Buffer’s (native) iOS app.

Extensions in iOS come in many different forms, but action and share extensions typically lend themselves quite well to being coupled right alongside mobile Safari. And where there is WebKit — there is JavaScript.

I’m not one to venture towards the world’s most recognizable scripting language unless I have to — much less without the aid of friends. Yet, there I was, sitting in my new office and requiring information from the DOM to complete the task at hand.

And so it is — my quest with iOS and JavaScript began. It turns out that the two opposites get along just fine.

An action extension’s meager beginnings can be traced back to the moment the user invokes them from the share sheet. Then — magic happens.

Specifically — the run method that’s found in the identified preprocessor is invoked. Utilizing the current page being handled by Safari — it returns a tidy, wrapped up JSON object to a completion handler. At this point, one can unleash their dirty Swift (or Objective-C) standard library mitts all over it.

Then, the fun.starts();.

Cupertino & Co.™ typically are associated with black boxing any and every process from the outside world. True though it may be, Mobile Safari comes at developers with a warm smile and welcoming arms.

It all depends on how the developer chooses to implement the JavaScript file. One can access the markup before or after the extension runs and even modify it all together after the extension finishes execution.

var GetTXT = function() {};
GetTXT.prototype = {
run: function(arguments) {
arguments.completionFunction({ “currentTxt”: document.getElementById('txt').textContent});
var ExtensionPreprocessingJS = new GetTXT;

Then, let iOS take over:

let extensionItem = extensionContext?.inputItems.first as NSExtensionItem
let itemProvider = extensionItem.attachments?.first as NSItemProvider
let propertyList = String(kUTTypePropertyList)if itemProvider.hasItemConformingToTypeIdentifier(propertyList) {
itemProvider.loadItemForTypeIdentifier(propertyList, options: nil, completionHandler: { (item, error) -> Void in
let dictionary = item as NSDictionary
NSOperationQueue.mainQueue().addOperationWithBlock {
let results = dictionary[NSExtensionJavaScriptPreprocessingResultsKey] as NSDictionary
let urlString = results[“currentTXT”] as? String
//Go crazy with DOM elements

They say there are an infinite amount of possibilities on the web. It’s also well documented that there is always an app for “that”. So, with JavaScript and iOS getting cozy, I think it’s only fair to assume that there are now an infinite of possible apps for anything on any platform, for both this and that. Did I get that right?

Of course, iOS only takes you so far. Fortunately, there are only a few steps an aspiring developer must take to mash the front end with Foundation. First, we must think about the actual .js file itself.

The rules here are simple. The developer’s responsibility is two fold:

  • Create a global object that’s named “ExtensionPreprocessingJS”
  • Assign a new instance of your custom JavaScript class to that object

This usually looks like our sample a few paragraphs above:

var Instance = function() {};
var ExtensionPreprocessingJS = new Instance;

Regardless of which platform one is crafting code for, the custom JavaScript function must define a run() function. Safari will load the supplied .js file as soon as the extension is run, at which point the run() function will be invoked.

At this point, Safari itself will dutifully supply an argument named completionFunction. Lastly, true to the web and restful APIs the world over, one can pass any results that JavaScript can handle in a JSON friendly key-value pair object.

var Instance = function() {};
Instance.prototype = { run:function(args) { args.completionFunction(/*Key-Vals go here*/); }
var ExtensionPreprocessingJS = new Instance;

One reason I love programming? You can get so cute when you want to. I mean that both metaphorically and literally. And so it is, JSON is to restful APIs the same as cats are to the internet.

Trust me, I am going somewhere with this. I think.

Enter the finalize() function. Safari invokes this function when the extension calls completeRequestReturningItems:Completion: as the very last step in its task. This means anything your extension brought in can be changed any way you want it to.

Which also means that with some hackery, things like this aren’t out of the question:

var CatDOM = function() {};
CatDOM.prototype = {
run: function(args) {
args.completionFunction({“URI”: document.baseURI});
finalize: function(args) {
document.body.style.backgroundImage = args[“cat.png”];
var ExtensionPreprocessingJS = new CatDOM;

Ah — what a time to be alive!

If you’ve developed any extension, or iOS app for that matter, you’re fond of the Info.plist file. This particular file plays an important role for the .js file, as it will happily inform Safari where to look for the JavaScript you want it to run.

Doing so is simple enough. The NSExtensionActivationRule dictionary can contain a key which points to the .js file one has included to the extension target. If the NSExtensionJavaScriptPreprocessingFile key is included, Safari will know to hunt down the file to execute.

They say change is a good thing. I like to fancy myself as someone who might be in a position to vouch for such a claim at this point in my life. As I embark on a new career, I’m learning new things daily and facing new challenges at a blistering pace that have been an adrenaline rush to tackle.

And, it’s been insanely fun. So, it only seems fitting that after several years of iOS development — I found myself mixing it with a scripting language I typically try to distance myself from. Something unexpected and new.

So — yes, I think it’s true. Change is good. Why not try something new today yourself?

Until args[“nextWeek”], stay frosty my fellow developers.

Jordan Morgan is an iOS software engineer who runs Dreaming In Binary.

If you learned something about using JavaScript with Swift, please NSRecommend this article below.

The Traveled iOS Developer’s Guide

Cocoa Touch, unwrapped and analyzed by @JordanMorgan10.

Jordan Morgan

Written by

iOS @buffer. Author for Pluralsight, contributor to a few books, conference talks and some other stuff! Writing at swiftjectivec.com

The Traveled iOS Developer’s Guide

Cocoa Touch, unwrapped and analyzed by @JordanMorgan10. Updated biweekly.

Jordan Morgan

Written by

iOS @buffer. Author for Pluralsight, contributor to a few books, conference talks and some other stuff! Writing at swiftjectivec.com

The Traveled iOS Developer’s Guide

Cocoa Touch, unwrapped and analyzed by @JordanMorgan10. Updated biweekly.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store