BrainOut!
The mumblings of a Christian autistic husband, dad, IT guy and amateur radio operator - Will Brokenbourgh / AF7EC
Not Everyone Can Be a macOS Developer
Lately it was necessary to use macOS to develop and test software and I was doing my customer support job on there as well. While I've had moderate success developing and testing on Linux and Windows, macOS is a whole other matter...
Not everyone can be a macOS developer.
Just to get this out of the way, I'm not a very smart guy. Yes, God has blessed me with the knowledge I need right when I need it, but for macOS development, while I've made progress, it's been painfully slow, frustrating and unintuitive. It got to the point that I decided to abandon my macOS development work and go back to Linux for now. In case you're wondering or bored, here's the sad tale...
Desire to be cross-platform
As you (may) know, I am the developer of
SpiritVNC-FLTK, a multi-view VNC client. While FLTK apps can compile
and run on a wide variety of operating systems including Linux, Windows and macOS, it
often looks out of place, with a Windows 95-look-and-feel that sticks out like a sore
thumb on Windows 11 or most modern versions of macOS. Personally, I will continue to
use the FLTK version of SpiritVNC because FLTK is very lightweight and relatively
easy to develop with, but it has been my desire to release native Windows and macOS
versions of SpiritVNC, so I thought I'd try to tackle the macOS version first.
I gave myself a decent head-start when I first tried doing a native macOS version back in 2018. I seem to remember having some problems back then and I would often have to step back from the project, taking a break until my brain recovered from the abuse that comes from Objective-C and Cocoa. So frustrating were those times that my young son made a cute "I Survived Cocoa" award from paper and colored pens, presenting it to me after many long hours of toiling with native macOS development.
"Grow a brain, Will, anyone can develop in macOS!"
No, that's definitely not true. Here are some things that trip me up when developing
on macOS:
• Xcode is buggy, unweildly and bloated. It got so bad that I decided to
ditch Xcode completely and develop the whole thing outside Xcode, in a text editor, and
use a Makefile to build. (In all fairness, MS Visual Studio is pretty
crazy and rough, too)
• Cocoa, Core Graphics and other macOS development technologies make it
harder than competing operating systems. Method names, parameters and flags
often are not intuitive and easy to figure out. In other technologies, if you want to
show a window or control, you do window1->show() or similar, while in
Objective-C and Cocoa, it's [window1 makeKeyAndOrderFront:nil].
• Things are sometimes difficult to find on Apple's development search
engine and sometimes important information is completely missing. I was trying to find
the documentation on flags for a Core Graphics image-creation command and it just
didn't exist. I had to search around the internet to see if anyone had working
examples, and often what I did find wasn't the right choice for my use case.
Quite often Apple documentation links to decades-old articles that show
deprecated methods and inaccurate information. (Yes, this is
the case for documentation in other toolkits and operating systems, but because Apple presents
their brand and technologies as 'premium', these issues shouldn't be as widespread)
• Some macOS apps just freeze for a while for no obvious
reason. I am using libvncserver /
libvncclient on all OSs and while it's an okay library, it's sometimes
tricky to interface with -- especially on macOS. Unlike the
gtk-vnc widget for use
with Gtk apps, you have to write your own message-processing loop with libvncclient.
Even after throwing sleep calls in this loop, it still seems to cause macOS
to freeze up and get confused. This even happens on SpiritVNC-FLTK built for macOS --
it's just something macOS does that's frustrating and doesn't typically happen on Linux,
though it's somewhat frequent on Windows.
• For some reason macOS uses a Cartesian coordinate sytem instead of the
fairly standard coordinate system nearly all other toolkits and OSs use. This causes headaches
when you're using libraries that expect non-Cartesian drawing. Another example of Apple
being different just because it's -- 'cool'...?
• Objective-C is not super-fun. I know that 'message passing' is
supposed to be 'safer' and 'superior' to just plain calling other methods, but
Objective-C feels burdensome with all of those brackets. Yes, I know you don't use
brackets in Swift, but Swift is a whole other ball of wax that I won't get into here.
Overall, it just seems that Apple was trying to be different for the sake of being different. Yes, some of their technological choices make sense and sometimes they truly are superior to other technologies, but for the unfortunate developers that typically live in Linux and / or Windows and have to subject themselves to punishment in the Apple development world, it can be brutal. Or maybe, maybe it's just me...?
For now I've completely unplugged my Mac and I'm experiencing relatively sane programming on Linux. To quote my dear friend "All operating systems stink". Yes, they all have their quirks and head-scratchers. macOS development is just so foreign and upside-down to me that it makes software development a burden instead of fun. God bless those folks who do it full-time and get through it and stay relatively sane!
If Apple listened to nobodies like me, how could they fix this?
• De-bloat Xcode or enable the IDE to be much more modulized so it doesn't
include every single feature and simulator out of the box, or provide an installer
for advanced users that lets you chose what you want to install and not a 'one-size-fits-all'
approach (again, for advanced users who know what they want. There should be a
'Minimal IDE and toolchain' install all the way up to 'The Kitchen Sink').
• Provide a C++-like interface with reasonable method names like
window1->show() instead of silliness like
[makeKeyAndOrderFront:nil]. I know Swift was introduced to liberate
Objective-C programmers from their bracketed drudgery, but coming from a C / C++ / Free
Pascal background, Swift seems like a 'me too' answer to Rust, which itself is not all
that fun if you have a developmental disability.
• With all of Apple's spare cash sitting around, they should hire a
team to go through the online documentation and make sure it's accurate. This team
could also modernize the ancient conceptual documentation and make sure it doesn't go
against current / modern best-practices. Also refreshing those pages' style so they
don't look like something out of OS X Snow Leopard would be a nice touch too (though Snow Leopard was a pretty cool release back in the
day).
• When apps freeze, a helpful log entry in Console would be nice. As
it is, there's a 'spin' log category but there was not one entry in it. The general
log made a note of apps freezing, but it was lacking useful details and only gave a hex
result code.
So my humble suggestions to any company that wants more quality and
quantity app-wise:
• Don't despise the devs who are trying to make apps for your
platform. Give them quality tools that don't crash every five seconds. Make things
understandable for the general developer population, not just elite developers
who are your platform's platinum fanboys. Some developers are working with multiple
OSs and frameworks so making it easy to bounce back and forth easily makes life easier.
• Provide great documentation, and make it easy for beginners,
intermediate and seasoned developers to find just what they're looking for. Make sure
every method, parameter, enum and flag is properly documented and that a useful explanation
of each exists. If you're worried about overwhelming beginners, hide detailed
information but make it easy to discover and view when required.
• Don't complicate things and instead make it easy for beginning
developers as well as seasoned pros to be productive. It's not a good idea to give babies
power tools to play with, and professionals don't want to limited by toys. Make the IDE
configurable based on the developer's experience and what they are targeting and don't force
one singular configuration for everyone.
• Since AI is all the rage right now, develop a good model that will
allow valid feedback from third-party developers to be routed quickly to the appropriate
group within Apple, Microsoft and so-on. Make it easy for valid feedback and bug reports
to get where they need to go while limiting lazy 'help vampire' requests.
Will I ever try macOS development again? Maybe someday, but that really depends on Apple, my financial situation and living situation. I really don't want to give Apple any more of my money for a machine that can run the latest macOS due to Apple's overt paganism and apparent privacy hypocrisy. While plenty of God-loving people and conservatives use Apple's products and need apps, beating myself up to enrich Apple isn't a priority.
God bless you, and thank you for reading!
About me
First and foremost I'm a follower of Jesus Christ. After that, I'm a blessed husband,
father and grandfather. I do remote computer work for a living although it's mostly
part-time. I'm an amateur radio operator - AF7EC. When I'm not working on the endless
list of house and car projects, I like to tinker with electronics, like to listen to
shortwave radio and write software (mostly open-source) in C, C++, Python and Free
Pascal. I usually run Linux as my main operating system but sometimes I'm forced to
endure macOS and Windows 11 for gaming with my son or testing software. Overall, I am
a big nobody, but always willing to share about Jesus and all that God has done for me
and my family.
Comments
(No comments yet)