Modularity Is What We Need

Brent Simmons post on his inessential.com about sharing code between iOS and macOS made a lot of sense to me and I’d like to double down here.

Modularity goes a long way for a lot of things and writing code is not excluded from this. A little extra work upfront may allow you to branch out into platforms in the future that didn’t yet exist or you didn’t anticipate at first. A good credo to follow here is “Don’t repeat yourself”. Writing little helper classes that do common tasks for you will pretty much work on any platform (watchOS & tvOS included) and will make you a better developer. Callback functions are great, cheap and once you get used to the syntax (fuckingblocksyntax.com is your friend) you’ll have modular code in no time. I would argue that anyone writing iOS apps today would be able to move and tweak their existing business and networking logic to an internal library within a couple of days.

Brent writes:

Assuming there’s a data model, maybe a database, some networking code, that kind of thing, then you can use that exact same code in your Mac app, quite likely without any changes whatsoever.

That leaves the 20% or whatever that’s user interface. AppKit is not the same as UIKit, but it’s recognizable. Same patterns and concepts, and often similar names (UITableView/NSTableView).

Simply copying over the class files will get you up and running in literally no time. That leaves you only having to worry about AppKit. As someone who has learned UIKit first and hasn’t done much with AppKit I’d say that it’s harder to pickup for sure but not as impossible as some people make it out to be. You have to become familiar with managing multiple windows and the tooling around it while trying to stay productive. One thing that Brent completely disregards though is that UI work is maybe only 20% of the work but appears to always take 80% of the time, which means that developers would have to spend 80% of the time developing the Mac app dabbling with technologies they’re unfamiliar with. This may be intimidating to some.

The lacking advancements from Apple in regards to tooling isn’t what has once again sparked the Electron vs. native Mac apps debate though. The bigger issue here is rooted amongst the upper management in my opinion. Jonathan Wight pretty much nails it in my opinion:

A lack of interest in providing a good experience on all platforms is the real issue that we’re facing.

Brent continues:

Ten years ago I thought that all the new iOS developers would translate to lots more Mac developers. That that didn’t happen is a huge surprise to me. Because if you’re an iOS developer you’re practically a Mac developer already.

I think Apple is partly to blame for this. The company is famously not very good and doing multiple things well at once. They seems to always focus on one thing in particular and let other things sit for quite a while until it’s in real trouble, like the Mac currently is.

Look at all the apps that are native on iOS. Wouldn’t it be great to see these companies put a little bit of work into splitting up their business logic from their UI code and “porting”, for lack of a better term, their app to macOS?

How great would a native Netflix or Amazon Prime Video app be on macOS that would let you download shows for offline consumption like on iOS? Or how great would a native Instagram macOS app be that would let “influencers” really boost their business, post engaging content more easily and allowed them to upload professionally edited “social cuts” of promo videos without having to copy the videos over to an iPhone and uploading them to Instagram there?

There are many things that would make macOS a better platform if a few developers spend a little bit of time on making their apps more modular.

26.04.2018