I started writing iOS applications in 2009. By 2012, I had immersed myself deeply enough in the world of iOS development that I had co-authored a book on Objective-C. I took a great deal of professional pride in crafting delightful user experiences in iOS applications, and thought I would carry on this kind of work for a long time. (You can read the whole story here).

After I started at Artsy in 2014, I began branching out. Way out. I started helping the platform team maintain our Ruby/Node.js/Scala APIs that our iOS apps relied upon. Using JavaScript, I developed UIs for tools that helped Artsy build its business. I grew. Nowadays, I spend my time building ”roads and bridges” to help my colleagues be productive in Artsy’s React Native codebase (which is open source).

Let me put it to you this way: at companies with both iOS and web developers, those two groups often don’t overlap. Or even interact all that much. They don’t share programming languages, they don’t share developer tooling, sometimes they are on entirely different teams from one another. They are distinct teams with distinct cultures.

In my work at Artsy, I no longer feel that distinction.

My point is that my deep experience in both native iOS and JavaScript software development has given me an uncommon perspective of seeing both communities from the other one’s perspective. When I write native iOS, I miss Jest and Prettier so much. When I write React, I miss Apple’s polished profiling tools and their opinionated APIs. I have a foot in both worlds, and I try to share that perspective with other software developers.

You might think this sounds awful – that I only see the downsides of both platforms. And yeah, that’s actually something I’ve had to deal with. But it’s not all bad: dual perspectives help me share the best that each world has to offer with the other. It’s why Artsy’s entire engineering team now has a healthy, conservative policy about adopting new dependencies. It’s why our web engineers, even if they’ve never done iOS development before, can pitch in on iOS work when we have a tight deadline.

This “we all have so much to learn from each other” idea is kind of my whole… it’s my whole thing. Like, if I had to distill the drive of my professional practice into a single sentence, it would be: “We all have so much to learn from each other.” I care about this a lot. In 2014, back when Swift was still in beta, my first ever talk on Swift was a call to action: we Swift developers need to steal the best ideas from other programming language communities. Moya was one of those ideas.

And so when I saw SE-250, a request from the Swift community to have Apple Swift develop an “official” Swift style guide and tooling to enforce it, despite existing community options, a distinction crystallized in my mind. It kind of hit me, actually. A huge difference between the cultures of the two communities.

I did try to be value-neutral in my wording, though I admit that it’s not obvious from what I wrote that I do see value in both approaches. And this tweet definitely generalizes both communities – there are folks with these attitudes in both camps. I followed up with this note:

This is really key: pointing out a difference exists isn’t the same thing as asserting “this is good” or “this is bad”; it’s just “this exists.” I’m endlessly fascinated by these differences and I’ve learned that you can only really learn from a difference if you approach it with an open mind and genuine curiosity. (This skill, of being interested while staying neutral, is something I learned in cognitive behavioural therapy.)

Thank you to everyone who responded with their own perspectives; for the rest of the week, I had a lot of interesting discussions. I now have more to share about the distinction between JavaScript and native iOS – admittedly, Twitter was never the right medium to explore these nuanced ideas, so I’ve written this blog post! Let’s dive in.

My absolute favourite reply came from Reginald Braithwaite, who compared the difference between native iOS and JS to the difference between renting and owning your home:

The reason I love this response is because I think there are benefits to both renting and owning your home. I like renting, actually, because it keeps me mobile – I can pick up and move from one city or neighbourhood to wherever I want. It’s not for everyone, but it’s right for me at this point in my life. (And I couldn’t afford to buy a house in Manhattan anyway, so.)

I approached this response with that same open mind, and I realized that this is the perfect metaphor for comparing native iOS and JavaScript development. Native developers get a tonne of awesome advantages to having a single, authoritative platform owner; from that perspective, asking Apple to build a new tool to help iOS developers makes a lot of sense. But just like there are also disadvantages to renting, there are disadvantages to having Apple own your platform.

Similarly, there are advantages and disadvantages to owning your own home! And just as with home ownership, JavaScript confers its own set of advantages and disadvantages.

Personally, what makes these two distinctions (renting-vs-owning and native-iOS-vs-JavaScript) map so well onto each other is because I believe that anyone unwilling to acknowledge the advantages and the disadvantages of both sides is trying to sell something.

Not to mix metaphors too much, but I was reminded of this Steve Jobs WWDC Fireside Chat (25:02) from 1997. Jobs also used the metaphor of a building to describe how software gets developed:

Jobs is saying that a team can only really build an app that’s so complex, but they can start building from a higher starting point to build a building/app that nets out to be higher/better. Those starting stories of the building are Apple’s tools and platforms. When I first saw this video a few years ago, so much of Apple’s behaviour “clicked” for me.

Apple sees themselves as landlords. Remember: no value judgement (I’ve had some bad landlords, too). They see their role as a provider of foundations, upon which software can be built; Apple benefits because better software built on their platform increases the value of that platform. Developers benefit because they can make better software on those foundations.

So let’s explore this a little bit. Apple is acting like a landlord, okay. As an iOS developer, I pay rent to Apple but I get to benefit from having an awesome home that someone else maintains. So what are the JavaScript developers doing? How does a home-ownership mentality affect how they build software?

Turns out, it affects it a lot. JavaScript developers feel a profound sense of ownership over their tools and frameworks. No company owns the platform, so in a sense, all JavaScript developers own it. I struggled to describe this ownership concept until Reginald Braithwaite’s tweet; I owe him for helping me put words to this feeling.

When I write native iOS code, I feel like a renter. When I write JavaScript code, I feel like a homeowner. With all the benefits and drawbacks of each.

While Apple might be able to provide a great foundation, I’m a roads-and-bridges kind of developer. I want to be able to improve my own tools, and I often find myself frustrated. Apple might have those twenty three stories to build on top of, but the JavaScript ecosystem is huge and they’re questioning the idea that you can only build so much complexity before it collapses under its own weight. That’s great – I love questioning dominant paradigms! But it’s also terrifying. Used responsibly, JavaScript can be used to start on a higher floor than native iOS development and help you erect ten stories of scaffolding – all on a platform you own.

It’s important for me to re-iterate that neither one of these is “better.” They are different languages, with different goals and different constraints. Any comparison between the two is necessarily apples-to-oranges. And while I enjoy getting to use them both, that comes with its own costs. We’re all on our own paths, and that’s totally okay.

With all that said, with open hearts and clear minds, I’d like to share some of the practical affects of this rather philosophical distinction. What are the actual advantages/disadvantages to both native iOS and JavaScript? In what’s sure to make everyone mad, I’ve mocked up a conversation to describe why native iOS and JavaScript development are both so amazing and both so awful.

Go ahead and hit “Send” to get started. (Note: if you prefer, you can read the source code with this conversation’s script on GitHub. Scroll about halfway down.)

This isn’t a compressive list, and my opinions are constantly evolving. I try to be aware of my biases and blindspots, and I try not to assume that my experiences apply universally. These observations are obviously based on my experience of moving between iOS and web, which isn’t typical.

What’s important is that when you see a difference between what you know and what someone else knows, you approach that with an open mind. Don’t jump to conclusions. Be curious about differences and always look for something you can learn.

If you’re an expert in one thing, it’s going to feel uncomfortable to branch out and become a beginner again. It was terrifying for me. But if you push through that discomfort, you can gain valuable perspective that will only help you be a better professional.