Ep.24 — Open source, giving back and trip simulation in Xcode iOS simulator

I am particularly encouraged by tech giants like Microsoft (who has 3500+ open-source repos on Github) and Google who continue to embrace the open source ideals and give back to the community as they invent their next big things.

Did a little giveback myself and open-sourced a Trip Simulator to make life easier for developers who create location-based iOS apps.

At the same time, I took the opportunity to dig deeper into Swift, macOS native app development and gained some first-hand perspectives into the upcoming Apple Silicon Macs.

Here are the top 3 learnings from my journey to Mac app development:

I. Architectural Choices

There are 4 main paths to building a Mac app. They suit different needs:

1. Traditional AppKit framework: Truly native to Mac. UI in storyboard, logic in Swift. Direct access to hardware and maximum look-and-feel alignment with the macOS experience.
2. Port from iOS: Take your iOS code (based on UIKit), create a new Target (Mac Catalyst) and optimize the UI by taking advantage of macOS specifics such as menu bars, window resizing, drag-and-drops, Touch Bars, etc.
3. Next-gen SwiftUI: This is Apple’s new universal architecture for building apps across Apple’s environments (macOS, iOS, tvOS, watchOS). Similar to Flutter, it’s declarative and offers instant UI previews (which is cool.)
4. Cross-platform Electron: It continues to offer a good option if you don’t need to use many platform specific features. Many prominent Mac apps are actually Electron-based: Github Desktop, Slack, VS Code, Discord, WhatsApp Desktop, etc. In this case, your mac app is essentially a web app wrapped by the Electron runtime which allows you to build most of the logic in JavaScript/TypeScript and also go to native API when needed.

All of them are valid choices. SwiftUI is less mature, but offers the longest runway going forward. For this project, I chose #1 and not to use SwiftUI at this moment because:

• There are many kinks that Apple needs to work out in SwiftUI
• Stack Overflow doesn’t have lots of answers accumulated yet
• There are few open-source projects that can be used as strong starting point and examples yet.

II. Swift all the way

The 2nd learning is around transitioning from Objective C. Unless you are fixing existing code, new stuff should be written in Swift, period. Don’t defer learning Swift (no, it’s not very intuitive if you are used to cousins of C language like Java or C#)

However, it’s ok if you walk in with the mindset of building more durable assets, and accept that Swift is better on certain things, but not so good on others. Its weirdness comes from a few places and once you understand them, it’s not too bad.

1. It reuses well-known keywords, but they mean slightly different things (e.g. in Swift, “let” denotes a constant; “var” denotes a variable.) These little things can be annoying for JavaScript fans.
2. Uncommon usage of special symbols like ! and ? — — ! is particularly confusing — it can be used with type name (which means non-nillable), and variable name (which tells the runtime: if the content is nil, stop) and even keywords like “as!” (Downcast, if failed, stop)
3. Sample code is harder for learners to follow because inferred type is encouraged and shorthands are often used to make things concise.

III. Apple Silicon Macs anyone?

Mac is in transition away from Intel CPUs. If you are current Apple users, I think you will like the upcoming Macs powered by the same CPUs running iPads/iPhone today. The new Macs will inherit millions of iOS apps out of the gate. In fact, iOS developers have to opt out if they don’t want their apps to be offered on the Mac AppStore as well.

In this Trip Simulator project, I intentionally spent time writing code using both the Developer Transition Kit (basically a Mac Mini with the A12z CPU) and my main Macbook Pro 16" (Intel Core i9) to get a preview of how it feels like. I was pleasantly surprised by the experience as a developer. Smooth transition between two different CPUs (both running Big Sur Beta 4) compiling and running my Trip Simulator app. No workarounds at the application level needed.

Hope this helps.

Until next time…