I agree it isn't optimal. But, Apple is asking all their downstream library authors to migrate to a new platform and support the old one (via "universal binaries").
It just isn't feasible or practical for app developers nor for the library authors, especially when those authors are providing free and open source libraries.
I wouldn't have imagined it possible, but we are shipping a x86 binary that uses a lot of open source libraries, that do video compression and decompression. And, Rosetta is incredible and the performance is amazing despite it all being x86.
The M1 is a feat of engineering and Rosetta is an incredible and unexpected part of that marvel.
I can't compile my code until a downstream library compiles their code. They can't compile their code until a downstream library, they depend on, compiles their code. It all has to happen before any of it can happen. It eventually will, but we'll have to be patient, as is always the case with global changes.
The SSL library is nobody's core business, yet every business depends on it. Most libraries are just infrastructure, way down, that we build stuff on. Core business has a specific meaning:
> the business activity that is main source of a company's profits and success
Maintaining libraries is not the core business of those that use those libraries, most of the time. That's why people use libraries.
This is it an either/or: you can find the problem libraries and submit the work back upstream so you don’t have to maintain it. Then, for the upstream that don’t cooperate, fork temporarily until you find an alternative.
To their point, all of this is not trivial. You could just compile as x86 and be done with in in 5 minutes, assuming the performance hit is acceptable.
> long-term maintenance cost if upstream accepts the patch
When they said "maintain", I read it as short term, doing this if and when for all libraries down the dependency chain. Or, compile as x86, and wait until external resources push for the support.
This seems to be an artifact of using Qt Creator. Generally speaking it is just a matter of running the same compilation steps with different targets (so long as you don't have arch-specific stuff in there like reliance on aliasing behavior or specialized simd, of course). Qt uses just about the most complicated build process I've seen outside of Xcode/objective-c++.
I'm curious to compare what the GTK build process looks like as a universal binary; I think RawTherapee has done it.
Give me a GitHub action template that builds universal Qt binaries for Mac given an existing cmake-based build workflow and I'll consider it. Until then, it was already enough work piecing things together for a regular Intel app-bundle because every howto you'd find does things differently and none of them are a perfect match to your setup. Even windows was easy compared to that...
I’m not going to say I’m an expert, but I’ve cataloged every electron error and show-stopper for an app I’ve built and deployed on windows/macOS for 5 years. Feel free to get in touch with me if you’d like help, or maybe just a slack channel where you can scream into the void. Best of luck, this stuff is CHALLENGING.
macdeployqt (which comes with Qt) has support for those things. Are you using that utility? There are other options, but macdeployqt has a nice combination of switches like -dmg, -sign-for-notarization, -appstore-compliant, etc.
We do this internally at my company with Qt5.15.2. We built Qt from sources for both Apple Silicon and Intel first and used those outputs in our app builds.
The tl;dr is that you have to build your Apple Silicon binary with Qt for Apple Silicon, build the x64 binary with Qt for Intel, and then use the Apple "lipo" tool to stitch the two together. This can all be accomplished on an Apple Silicon Mac.
The tricky part for me was figuring out that I had to switch the shell to x86_64 to run the compiler tools for the Intel build, after running the compiler for the Apple Silicon build under an arm64 shell.
I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that.
Apple has not changed its policy in over a decade: they don't care about software devs, they don't want you to release your stuff there, and only the biggest companies who are willing to throw dev after dev at the problem get to participate in the walled garden.
Screw 'em, release your software on Windows and Linux and don't look back.
> I used to think it'd be easier to just not support Macs at all for most smaller tech companies, and after reading this, I still think that.
There is only one platform to support: macOS. I can target all supported Mac users 100% of the time. Windows is similar and is also one OS to support and one can target their Windows software to Windows users 100% of the time.
> Screw 'em, release your software on Windows and Linux and don't look back.
How do you define Linux support especially when you cannot guarantee supporting all Linux users and distros?
Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro. Games are a bit more iffy, depending on if it used SDL or not; and Steam on Linux has made great effort to make the (admittedly few) older Linux binaries remain alive (and if Steam doesn't, the community has).
I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user. One gets me a customer for life, the other just reminds me that hell is other people.
That isn't good enough. It is not a guarantee of full OS support and you are forced to select a limited set of distros that you can support despite them all running a Linux kernel.
That is not the case with Windows or macOS which the majority of users have been using for their Desktops for decades. [0]
> I don't see this as an issue. Using Linux implies a level of competency from the customer, and I'd rather help a competent Linux customer try to get my stuff run on their odd distro (ex: Alpine) than help an incompetent Windows or OSX user.
Why should one always assume that their customers are kernel engineers or know what a compiler is to get their GUI app running on their system? I would not give free or paid support on unsupported systems, especially when the Linux user-base is vanishingly tiny.
If your software can be run by tech-illiterate users on Windows / Macs and they are paying for it, that is a much better outcome than wasting hours helping one Linux user run your software on an obscure distro either for free or paid.
> Binary Qt and GTK apps compiled even 10-15 years ago often still work, and do so on almost any distro.
That hasn’t been my experience at all. Also, the desktop Linux market is minuscule. It is an order of magnitude smaller than the macOS market. There’s a reason commercial software vendors don’t usually bother with it.
* You have to setup the binary to build N times (done automatically if you use the tools apple provides while apparently not caring about developers)
* In this case you have to setup a non-standard UI toolkit, which obviously is going to make things harder, and make that build universal as well. Qt claims to support mac and iOS so I'm surprised that doesn't happen by default
* Codesign, which is a trivial step
The hardest part here is just the "I don't want to make a native app so I'm going to build an entire 3rd party UI toolkit", which is not an argument that apple doesn't care about devs.
If I were to make a normal desktop app with a UI, I'd consider Qt before the rest of the toolkits (at least, until Iced finally catches up). Even on an OSX-only app, I'm sure as hell not using SwiftUI/UIKit/etc. Qt more consistently nails native apps, the so-called-native UI toolkit on any given OS doesn't.
You seem to think "codesign" is the trivial step: it is not. Many many times that entire step has made it to the top of the front page on HN, on how many dev teams simply cannot get this to work right consistently, and will break in ways that cannot be debugged using the tool output or the documentation.
Nobody has this level of problem on Windows: I just sign it using a valid cert, and its done. I don't need to buy a Microsoft-made computer or need to run Visual Studio or pay Microsoft $100 a year and then still have random reports of Windows users being unable to run my binary; however, HN has popularized countless stories of devs being forced to buy a Mac (which means no OSX in a VM, no OSX build farms, very spotty CI<->OSX integration), having to pay Apple $100 a year to notarize the signing (which they can also refuse to do, without recourse), having to use XCode (at least for the signing step), and they still have situations where the binary is not being signed and/or notarized, or OSX will randomly fail to run the binary, or it actively prevents users from running the binary without telling anyone why, but giving scary messages to non-tech users anyways.
I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem.
You do not need Xcode for signing or notarizing, period. I’ve set this up for open source projects that sign and notarize via CI and it literally doesn’t break. The flow is like reading reviews of an apartment complex - complaints will rise to the top but it’s not like people are going to write glowing reviews otherwise. ;P
Furthermore QT on macOS literally links to and renders the same controls as AppKit under the hood, so while you can definitely use it if you want (e.g for cross platform benefits) your claim that it “nails” platform specific UI is just incorrect. They are fundamentally the same thing in this case.
You appear to have this irrational idea(and hatred…?) about how macOS/iOS developers work but don’t appear to truly understand what you’re talking about.
If I were to make a normal desktop app for Mac I'd use AppKit.
IMO, a lot of the UI things apple has introduced in the last few years have been attempting to get the people making apps for iOS to also make them for macOS in a way that isn't just an iOS app running on a larger screen.
I guess the alternative is that everyone continues making these horrific apps built on top of chrome wrappers like electron, bring Sun's vision of everyone shipping a single crappy app to every platform.
> I'm sorry, but how the hell is a trillion dollar company getting this wrong? Apple has broken priorities, and shilling/fanboying for them on here is not going to fix the problem.
I'm sure you have a solution then? One that doesn't require the alternative of "every app must be from a central store that reviews and approves every app"?
> shilling/fanboying for them on here is not going to fix the problem.
Name calling and personal attacks doesn't help anyone, and it certainly doesn't inspire me to think you're willing to argue in good faith.
Let me not mince words: People who are pro-Apple on HN have a long established history of not arguing in good faith. They belong to a cult, and viciously attack anyone who isn't part of the tribe; often attacking them for the same "crimes" that Apple itself is better known for.
Also, yes, I have a solution, the same solution everyone eventually follows: they switch back to Windows, they get angry at Microsoft for whatever reason (Microsoft comes up with a good one every 7-8 years), and then they switch permanently to Linux.
I used Linux as my primary, and only, desktop OS from when Windows 95 started shipping on PCs in 1996 to about 2015, where I allowed Windows back into my life. My laptop is a MBPR that very quickly proved that OSX is not, and never will be, prod ready (to my credit, I made it a year and a half before I gave up); it then got swapped to Windows, and ran that way for a few years until it now runs Linux.
From my vantage point, Linux adoption on the desktop is an Eternal September, and I'm fine with it. Everyone makes it here sooner or later if they're serious about computers and/or software development.
The solution to fixing Apple, however, is doing what Microsoft did: quiet fired/force retired Balmer, promoted a strong candidate from within, and let him right the ship; Apple needs to replace Tim Cook with whoever their equivalent of Satya Nadella is.
> Even on an OSX-only app, I'm sure as hell not using SwiftUI/UIKit/etc. Qt more consistently nails native apps, the so-called-native UI toolkit on any given OS doesn't.
In my experience this varies a lot between projects and developers. Some Qt apps are great (Krita comes to mind) but just as many are quite janky. Of course AppKit/UIKit have their fair share of bad apps too, but generally if developers have gone as far to commit to building their app with either (especially AppKit, which is the less accessible of the two) they take extra care to produce a good product.
Qt being for most intents and purposes usable only with C++ and Python likely impacts this, though. A lot of devs aren't particularly keen on either language, especially with the extra headaches that come with shipping a user-facing multiplatform Python app that reliably runs everywhere.
Apple requires “notarization,” not just code signing. If you code sign your app and don’t “notarize” it, it will refuse to run. Like it will be harder for the end user to run it than if you had not code signed it at all. Submitting for “notarization” requires an Apple developer account with an active paid subscription and payment method. You have to upload it to Apple and wait for it to be approved in an asynchronous process which can sometimes take tens of minutes each time.
you only do that for the final build. It does prevent unscrupulous malware distributors, since there's now a paper trail linking it back to you if you did bad.
Of course, this could be abused by apple to gatekeep, and it doesn't prevent the user from downloading the app and bypassing this security measure (so does not in actual fact stop all malware).
Fancy terminal emulators (Warp?), browsers (Orion, Arc), some machine learning stuff (that Whisper GUI and ollama front-end) immediately come to my mind.
Anecdotally any single-platform launch on HN will be on macOS.
This is a Qt5 project and not really indicative of the actual development experience imho. Writing native software for native platforms with native UI and bindings is a big undertaking but worth it in the long term
Ah humans. As humans does one thing not rouse in us the thought of another? Do we not draw connections between two things? Are these connections Never amusing? Has the smell of a soap reminded us of a summer spent at childhood friend’s house? Or similar? Or are all moments of joyful connection drawn to a halt at the hand of the parser? Forgotten to case sensitivity?
Happily I've seen both QuickTime and "Qt" abbreviated as "qt", "Qt", and "QT" because human languages are often ambiguous (in fact all written human languages can have ambiguity, but not all have capitalization, so arguably the former ambiguity is more prevalent and important than the latter)
But, Rosetta is incredible.
My solution for now: build only on Intel based Macs and use the binaries everywhere, with Rosetta when needed.
I've had lots of errors running all kinds of builds with "error, arm64 code..." it's not a solved problem by a long shot.
Until the prevalence of M1/M2 is overwhelming, I'm just going to stick with Intel builds.