Edit: This post was HEAVILY critiqued and taken apart here: Download. A well deserved critique and although it doesn't do this post any favours, its worth listening to as I can totally see their points and I think I need to get better at posting 😂
This morning I was listening to the latest Stacktrace podcast by John Sundell and Guilherme Rambo where they briefly discussed the Mac, recent rumours and the stigma surrounding macOS development for iOS developers.
Having had a fair amount of experience across both platforms, I wanted to write a followup piece to cover some of the deeper issues that I feel prevent a lot of developers taking the plunge.
Note: I'm not trying to discourage would-be Mac developers, quite the opposite. There's a lot to be learned from the Mac and differences aside, its quite approachable to anyone with the willingness to learn the subtleties involved.
I began developing Mac apps about a year before the iOS SDK was released. I then started porting application(s) over to iOS the second it was available.
Over the years I've had the pleasure of working on various Mac and iOS apps, so I feel I have a pretty decent grasp on the difficulties involved. From my perspective there are a few key areas you need to be aware of:
- Product Definition
- User Expectation
- Device Testing
Although there are a lot of common lower-level frameworks where you can share your code between platforms, it'd be an understatement to say that getting from business logic to a product is simply a thin-UI-layer away.
Besides some of the technical obstacles, one that is often missed is the Product Definition.
What exactly is your product on a desktop?
Many apps are dependent on hardware features like location services, gyroscope, etc... Hardware limitations are not the only obstacle though. Many apps depend on access to the users Photo library for example, but until macOS 10.13 there wasn't even a consistent API for doing so on the Mac.
A mobile app is also typically used on-the-go, which heavily influences your design patterns and UX. When deciding to make a Mac app, often times these decisions will need to be completely reconsidered.
Historically macOS would handle multiple window instances, whereas on iOS you generally only use a single window in your application. This has improved with unified interfaces becoming the trend even on macOS, however there are still various elements that are fairly common practice and are surrounding by user expectations.
For example, menus, status & dock icons, etc...
A fairly obscure API for dealing with menu's for example, uses a legacy target-action approach paired with a few informal delegate methods that allow you to enable/disable, rename, etc...
If may appear more obvious when thinking about input (i.e. mouse/keyboard vs touch) however where things get really tricky is around user-expectations. On iOS you can be forgiven for ommitting keyboard shortcuts for example. On macOS however, some menus & shortcuts are provided with default implementations while others are left to the developer. With users expecting certain shortcuts to 'just work', leaving these kinds of features out is often just not possible.
Another feature that's often excluded from iOS apps is a full-featured Undo/Redo system. On macOS it would be heresy to leave this out.
While iOS 11 (on iPad) has now introduced a similar drag and drop API, many apps have yet to include this feature, especially if they are primarily used on an iPhone. The issue is compacted on macOS by the fact that many external interactions are generally expected by users and can be the difference between a working app and a work in progress.
There are a lot of similarities when developing for the Mac, however one of the most difficult things you'll uncover early on is testing across older versions of macOS. On iOS, you can simply plug in another device or run a different Simulator.
On the Mac however, you either need to use a Virtual Machine (which wasn't possible in the early days) or have multiple Mac's with various versions installed.
For me, this was always one of the biggest issues during testing. If you've been developing for Mac and have better solutions for this I'd love to hear about them.
Although you can submit your application to the App Store, this hasn't proven to be hugely successful for other applications on the Mac. This is largely due to user expectations around pricing.
Historically Mac apps have been slightly more expensive (albeit more feature-full as well). This paired with the fact that Apple takes a significant cut as well, have forced developers to continue to sell their applications outside the store instead.
While this can be financially beneficial, this also incurs some additional learnings. If you choose this approach yourself, you'll need to handle Automatic Updates yourself, as well as things like discovery and purchases. If you plan on things like in-app purchases you'll also be responsible for things like that.
There are also slightly more options around signing and sandboxing when you sell outside the store, but I'll leave that as an exercise to the reader to investigate themselves.
The reality is that although you can write pretty much all your business logic, persistence, networking and more in a cross-platform way, getting your app onto the screen will still require a fair amount of effort.
Subtle differences like view's not being backed by layers by default, origin at bottom-left (as opposed to top-left on iOS), vastly different theming approaches, etc... require careful planning in order to have as much shared code as possible.
That's not to say an iOS/macOS app can't be achieved – it most definitely can, but its going to require you to jump over a few technical and non-technical hurdles.
This isn't a comprehensive list of challenges but hopefully makes you a little more aware and feeling empowered to start developing for the Mac. If you'd like to discuss this further or would like some advice for planning your own macOS app, get in touch.